Re: Website and library packages
On Thu, Jan 17, 2002 at 02:46:29AM +0000, Matthew Garrett wrote:
> On Wed, Jan 16, 2002 at 09:16:10PM -0500, utsl@quic.net wrote:
> > * About packaging from /usr/src:
> > I had been planning on writing something similar to kernel-package for FreeBSD.
> > The basic idea was to do a make buildworld against the regular FreeBSD source
> > tree, and then make multiple packages out of it. (i.e. libc package, kernel
> > package, etc.)
>
> That's something which hadn't occured to me :) Yes, that probably makes
> things somewhat easier in some ways, although we end up with a rather huge
> source package. I guess that it would probably be somewhat stripped down
> to only include the stuff that we're concerned about? (That is one thing
> I've found, though - a couple of the source packages I've built include
> stuff from the kernel source, so building them both from the same package
> would reduce duplication)
A large source package isn't necessarily a big deal. Most people are probably
just going to use CVS, so the package that does the build could be separate,
like kernel-package is separate from kernel-source. I believe you can do
something with the supfile to limit which parts of the CVS tree it downloads.
That might help reduce the size somewhat.
It's not just duplication, there's also the fact that many of the userspace
utilities and libraries NEED to be built together with the kernel. It's a
feature in the BSD world. It'd be easer to keep them in sync if they're built
as packages which depend on an exact kernel package version.
> > That approach gets rid of a lot of hassles associated with upgrading the
> > sources, and allows people to rebuild their kernel and core system. You just
> > pull the new sources from CVS, and use the scripts to build debs. A lot like
> > kernel-package, except that it has to handle more packages.
>
> I've left the CVS directories in there, so it ought to be possible for
> package maintainers to deal with upgrades. On the other hand, the idea of
> a user being able to upgrade stuff in-situ sounds rather cool :) I'm not
> sure whether the best policy here is to stick with the existing Debian
> mentality of individual packages dealt with by different maintainers or a
> huge package with the user having more choice over updates as you
> suggest. What does everyone else think?
You could do a big source package in CVS, and have a team maintain it. That
seems oddly appropriate. ;-)
> > On a related note, FreeBSD's Makefiles use "make" sometimes where they should
> > use "${MAKE}", so I put the BSD make into /usr/bsd/bin. Then I mangle $PATH
> > before running make from debian/rules, so that the FreeBSD Makefiles always
> > get BSD make rather than GNU. Sounds like NetBSD has better Makefiles.
>
> Yup, this isn't something I've encountered so far.
>
> > * On the webpage, you mention problems with shadow:
> > I had the exact same problem with FreeBSD, and I see two choices. Either use
> > native passwd, adduser, etc. or get the shadow package to build a library (I
> > believe it can, but it's disabled), and recompile the Debian passwd and friends
> > with that. Then it's just a matter of getting PAM working.
>
> PAM seems to be working (due to the problems with passwd and company I
> haven't been able to check it too effectively yet), but there were some
> issues with applying both the NetBSD patches and the Debian patches. I
> think I got those sorted, but doing this in a clean way that works with
> the existing package isn't going to be a great deal of fun :)
Oh, but it's so educational! I've always found PAM to be a complete PITA to
get right.
> > I'd just use the BSD utilities. Most users probably either use ifup/ifdown,
> > or can figure it out. It should be much easier to modify ifup to know about
> > BSD-style ifconfig than to try to make some replacement that's compatible.
> > Besides, Linux already has both ifconfig/route and "ip", with totally different
> > semantics.
>
> Ah, that's true. Yup, the init scripts all use ifup now, so just having
> our own version of that ought to deal with the problem nicely.
I'd suggest that if it's at all possible, merge into the usual ifup.
---Nathan
Reply to: