conary - package management and maintenance?

[Martin Bähr]

On Mon, Mar 17, 2008 at 11:53:07AM -0400, Jesse Keating wrote:
> On Mon, 2008-03-17 at 16:31 +0100, martin f krafft wrote:
> > I recently encountered Conary[0] and initially thought of it as
> > a package installation manager, but it turns out that it also
> > handles the other side, the package maintenance side.
> > 0. http://wiki.rpath.com/wiki/Conary
> > 
> > Which version control system does it use?
> > 
> > Does Conary address the vcs-pkg goal, which is to marry maintenance
> > and version control, without requiring the entire distro to switch
> > the package manager or package format?
> 
> Or even more fun, can we use conary on the vcs-pkg side without having
> it on the package deployment side, that is can Debian use it to
> produce .debs for consumption, can Fedora use it to produce rpms for
> consumption, etc...

a few weeks ago i discussed these and related questions on the #conary
channel on freenode. the log of that conversation is now available from 
http://vcs-pkg.org/conary/

the short answers to the above questions are:
the version control system appears to be their own development (i didn't
ask about that last time, i'll poke them again for more details)

as for the vcs-pkg goal i am not sure. while it is certainly no problem
to produce deb, rpm or any other format as output (and thus make it
possible to use conary without the deployment side, it is not really
clear how much of the rest of the system would be replaced by conary.

the opinion seems to be that using conary just for the source would not
be worth it, because for pure source management there are better tools.
conarys strenght seems to be the close ties between source and binaries,
and the resulting binary/package versioning.

one thing i also did not ask (which i realize as i write this) is how
strong conary is tied to the build system. ie: would it be possible to
take eg an srpm and an rpm and load them into conary, and have identical
rpms come out the other end? note that it is possible to import rpm
packages already (but not yet deb or other formats). not sure if that is
useful for vcs-pkg (i have not yet read the list archive and related
material)


as for my own background and motivation of doing this:

i am interested in a world where the difference in linux distributions
focuses on content and quality and not on the packaging format. i don't
want to be forced to use a certain distribution just because the
application i need is only available there. every application should be
available on any distribution and packaging an application should be
like painting a bikeshed. ie it should not matter which format is used,
because it should be changable easely.

a common source backend that can be shared by all distributions can
hopefully help this goal, and that's why i am glad that this effort
exists.

other than doing a few deb backports and a few conary packages i have no
experience in packaging. i am an excited git user since less than a
year, have used sls, slackware, redhat (3.x-7.0), debian (since 2001),
ubuntu, and since end of last year foresight (which is conary based). 
(still using debian on servers and machines where foresight is not an option)

greetings, martin.
-- 
cooperative communication with sTeam      -     caudium, pike, roxen and unix
offering: programming, training and administration   -  anywhere in the world
--
pike programmer   travelling in china                   community.gotpike.org
unix system-      iaeste.(tuwien.ac|or).at                     open-steam.org
administrator     caudium.org                                    is.schon.org
Martin Bähr       http://www.iaeste.or.at/~mbaehr/