Hi,

On 06/29/11 18:05, Chris Bolton wrote:
I've actually been wanting to work on my own package manager for awhile.. might be interested :D

maybe you should take a look of pkg-get(8) first.

On Wed, Jun 29, 2011 at 4:31 AM, Moritz Wilhelmy <ml+crux@barfooze.de> wrote:
[...]
- because the system on the build machine is really lightweight, it
 makes it easier to find out about footprint mismatches and missing
 dependencies. This is probably the most important for people who don't
 actually intend to use my packages. I will report anything that
 breaks, be prepared for a flood in the bugtracker ;)

- The obvious: Build binary packages for crux; This is similar to BSD
 where ports as well as binary packages are being built. Since crux is
 influenced by BSD, why not? ;)
 If you're familiar with BSD, you might notice that the directory
 hierarchy is similar to the ftp trees of the major BSD distributions.

[...]

Well, did you think about the problems between build-dependencies and runtime-dependencies? so you should take care about the number of packages will be listed as dependencies, and also note that most -mature- binary package managers like apt-get, yum, etc. are plenty of options and switches to select which dependencies, versions or flavours (-cli, -gui, -fbdev, etc.) for the same package to install.

I think that working with deps it's not as easy, for example:

1. you have a package 'foo' that depends on 'bar'
2. 'bar' size is 100MB and contains some binaries, libraries, pixmaps, config files, misc docs and also library headers
3. What to do?
    a) listed 'bar' as a dep and split them:  bar-headers, bar-libs, bar (depends on bar-headers and bar-libs)
    b) listed 'bar' as a dep
    c) ?
4. What about when 'bar' changed their build dependencies? should you update them to?
5. Could you imagine the same scenario for a complete and large deptree of a package like smplayer which depends on qt4, mplayer, etc.
6. Do you think that the complete system will be easily maintainable?

IMHO is it not as easy, so the problem appears when you should decide between build or runtime dependencies and that should be solved as first.

- A binary package manager.
 We have pkg-get, but it's simply not made to play nicely on a lot of
 different setups, and requires custom files. crux-bin contains only
 ordinary crux packages,

What means ordinary packages for you?
because everything else is assumed to be in
 the ports tree. Maybe something that integrates nicely with prt-get
 by changing the "addcommand" and "makecommand" to default to binary
 packages for some few binary packages would be nice.

In the past I wrote a mail [1] talking about the use of prt-get as a package manager also for generated packages living in $PKGMK_PACKAGE_DIR, but to do the trick you'll need ports (always uptodate) + prt-get

I wrote that mail because I used to recycle my own build packages and shared them (via nfs) for an old laptop in which compile was completely discarded, but nowadays I think that most hardware are ready to use prt-get directly to build your own packages with the buildtime dependencies you have installed previously, and most important, with your own CFLAGS to optimize packages

IMHO the idea to have a binary repository with non-optimized packages it's fine for installations, but it's hard to maintain for more than the core collection, anyways I'm glad that people look for ideas to try to improve things, thanks.


[1] http://lists.crux.nu/pipermail/crux-devel/2008-June/003554.html (excuse my bad english explanation ;D)


Best regards,
-- 
Jose V Beneyto | http://sepen.mine.nu