Ideas for packaging FreeBSD binaries
Robin Elfrink
elfrink at introweb.nl
Thu Sep 8 06:48:49 UTC 2005
Aurelien Jarno wrote:
>>> Well the other possibility is also to get the sources from CVS, it's the
>>> way the kernel and freebsd5-buildutils are done.
>> Is that preferable? What does one know of stability/security in CVS? Or
>> would you just point at a certain branch/tag ?
> I don't know if it is preferable or not, it may depend on what you
> package and the way you package it. I mean in your case using the
> tarball could be a waste of space (see the other paragraph below). But
> for a single apps, that could be a good solution.
It's a bit of a waste of space perhaps, but the sources come in this
way. I could split the original tarball and make seperate source
packages, or take them from a specific stable CVS tag, but this is much
easier. Besides, more than half of this specific source package _should_
result in binary packages.
> For the CVS, I usually use the latest CVS version available for a given
> branch, which means it includes the latest security patches. The
> security patches that are published later are then put in the
> debian/patches directory in order to avoid to recreate the .orig.tar.gz.
Ah, ok. I'm thinking in 'stable' terms for myself, that's why I took
ssbin.aa from the known stable FreeBSD release.
>>> On another side, a too big source package will be difficult to maintain.
>>> What about make one source package by category. For example:
>>>
>>> freebsd-netutils: pf, ifconfig, netstat, route, ...
>>> freebsd-hwutils: atacontrol, kbdcontrol, disklabel, ...
>>> freebsd-kernelutils: kldutils, ktrace, mdconfig, dmesg, sysctl, ...
This is exactly what I was trying to accomplish, all from this one
source package :) Personally, I think this is the easiest way to
maintain them.
> The problem I see there is that we won't package all /sbin binaries from
> this package, as some of them will probably be provided by other debian
> package. This also mean we will have to check license issues for all
> stuff in the tarball instead of only the license of the /sbin binaries
> we want to provide. This will probably be more true for the bin package.
The whole tarball is distributed by FreeBSD as part of a FreeBSD
release, and, to my knowledge, falls under the same license.
Ah well. It's just an idea. Since IANADD I don't really care _how_ the
binaries end up on my machine, as long as the _do_ end up there :)
Robin
More information about the Glibc-bsd-devel
mailing list