[Announcement] crux-bin: binary packages for crux
Hi folks, I've been putting this mail off for a long time, but I finally decided to get some initial toolchain going, and it seems to work quite well so far. So this is crux-bin, a little community project that builds binary packages for crux. My project goals so far are: - 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. - A crux-specific source mirror: Most of the source mirrors out there seem to be for gentoo, which often means they are outdated or certain files are missing. Since I have to download the source files anyway in order to build the packages, I decided to download them from the original website only (which helps finding md5 mismatches, another side-effect), sort them by ports collection and put them into rsync. The build isn't automated yet, but I'll hack something together that will notify me if something breaks and build automated once a day via cron otherwise. Packages are stripped down to a minimal set after build to eliminate implicit dependencies. If you want these implicit dependencies, you can always build from source. I'll explain the details on demand. Things that are planned for the future (volunteers? ;) - 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, 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. - There are currently no x86_64 packages. I'm building this in an lxc-jail on a 32-bit ubuntu (the host system needs to run some old, 32-bit only software) on a spare i7 at work. If anyone wants to help out, be my guest, although I might wind up with something. I personally don't use 64-bit crux at all, because I only own 32-bit machines, so this feels a little pointless.. Thanks to pitillo and sepen for prt-clean and prologic for the offer to mirror my efforts! See rsync://crux-bin.wzff.de/ for a list of what's currently there, but it might still take a while until DNS is in sync. Note: This announcement will probably be my only mail regarding crux-bin to any of the official crux mailing lists since this is an entirely unofficial community effort that's not really related to the real crux and I don't want to spam anyone's inbox with emails about a project spinoff they don't care about, however there is a mailing list at crux-bin@lists.barfooze.de to which anyone interested can subscribe by sending a mail to crux-bin+subscribe@lists.barfooze.de. Best regards, Moritz
I've actually been wanting to work on my own package manager for awhile.. might be interested :D On Wed, Jun 29, 2011 at 4:31 AM, Moritz Wilhelmy <ml+crux@barfooze.de>wrote:
Hi folks,
I've been putting this mail off for a long time, but I finally decided to get some initial toolchain going, and it seems to work quite well so far.
So this is crux-bin, a little community project that builds binary packages for crux.
My project goals so far are:
- 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.
- A crux-specific source mirror: Most of the source mirrors out there seem to be for gentoo, which often means they are outdated or certain files are missing. Since I have to download the source files anyway in order to build the packages, I decided to download them from the original website only (which helps finding md5 mismatches, another side-effect), sort them by ports collection and put them into rsync.
The build isn't automated yet, but I'll hack something together that will notify me if something breaks and build automated once a day via cron otherwise. Packages are stripped down to a minimal set after build to eliminate implicit dependencies. If you want these implicit dependencies, you can always build from source. I'll explain the details on demand.
Things that are planned for the future (volunteers? ;)
- 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, 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.
- There are currently no x86_64 packages. I'm building this in an lxc-jail on a 32-bit ubuntu (the host system needs to run some old, 32-bit only software) on a spare i7 at work. If anyone wants to help out, be my guest, although I might wind up with something. I personally don't use 64-bit crux at all, because I only own 32-bit machines, so this feels a little pointless..
Thanks to pitillo and sepen for prt-clean and prologic for the offer to mirror my efforts!
See rsync://crux-bin.wzff.de/ for a list of what's currently there, but it might still take a while until DNS is in sync.
Note: This announcement will probably be my only mail regarding crux-bin to any of the official crux mailing lists since this is an entirely unofficial community effort that's not really related to the real crux and I don't want to spam anyone's inbox with emails about a project spinoff they don't care about, however there is a mailing list at crux-bin@lists.barfooze.de to which anyone interested can subscribe by sending a mail to crux-bin+subscribe@lists.barfooze.de.
Best regards,
Moritz _______________________________________________ CRUX mailing list CRUX@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux
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 <mailto:ml%2Bcrux@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
Hey, Just a quick note to say that I would more likely participate in this project if you moved the mailing list over to Google Groups (or something). Recently I unsubscribed myself from many mailing lists as I simply don't have the time to sit there going through my (what was) enormous inbox :) cheers James James Mills Director | Short Circuit Services Pty Ltd james.mills@shortcircuit.net.au | shortcircuit.net.au Mobile: 0488 33 44 81 On Wed, Jun 29, 2011 at 21:31, Moritz Wilhelmy <ml+crux@barfooze.de> wrote:
Hi folks,
I've been putting this mail off for a long time, but I finally decided to get some initial toolchain going, and it seems to work quite well so far.
So this is crux-bin, a little community project that builds binary packages for crux.
My project goals so far are:
- 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.
- A crux-specific source mirror: Most of the source mirrors out there seem to be for gentoo, which often means they are outdated or certain files are missing. Since I have to download the source files anyway in order to build the packages, I decided to download them from the original website only (which helps finding md5 mismatches, another side-effect), sort them by ports collection and put them into rsync.
The build isn't automated yet, but I'll hack something together that will notify me if something breaks and build automated once a day via cron otherwise. Packages are stripped down to a minimal set after build to eliminate implicit dependencies. If you want these implicit dependencies, you can always build from source. I'll explain the details on demand.
Things that are planned for the future (volunteers? ;)
- 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, 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.
- There are currently no x86_64 packages. I'm building this in an lxc-jail on a 32-bit ubuntu (the host system needs to run some old, 32-bit only software) on a spare i7 at work. If anyone wants to help out, be my guest, although I might wind up with something. I personally don't use 64-bit crux at all, because I only own 32-bit machines, so this feels a little pointless..
Thanks to pitillo and sepen for prt-clean and prologic for the offer to mirror my efforts!
See rsync://crux-bin.wzff.de/ for a list of what's currently there, but it might still take a while until DNS is in sync.
Note: This announcement will probably be my only mail regarding crux-bin to any of the official crux mailing lists since this is an entirely unofficial community effort that's not really related to the real crux and I don't want to spam anyone's inbox with emails about a project spinoff they don't care about, however there is a mailing list at crux-bin@lists.barfooze.de to which anyone interested can subscribe by sending a mail to crux-bin+subscribe@lists.barfooze.de.
Best regards,
Moritz _______________________________________________ CRUX mailing list CRUX@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux
Hello, I just wanted to inform you that there is a website now at http://crux-bin.wzff.de:8080/ (Sorry, can't run it on port 80 for now). Since pkgutils don't support downloading via rsync (yet? was this ever planned?), this might make the distfiles section more interesting. FTP is not planned for now. Best regards, Moritz
participants (5)
-
Chris Bolton -
James Mills -
Jose V Beneyto -
Moritz Wilhelmy -
Moritz Wilhelmy