Subject: Re: Managing lots of installed packages, buildlink and versions
To: Alan Barrett <firstname.lastname@example.org>
From: Frederick Bruckman <email@example.com>
Date: 05/19/2002 20:08:56
On Sun, 19 May 2002, Alan Barrett wrote:
> On Sun, 19 May 2002, Greg A. Woods wrote:
> > How do you propose to do that -- i.e. implement a means of allowing
> > flexible from-source dependencies but sticking to fixed dependencies for
> > binary packages? It would seem on first glance that such goals are
> > diametrically opposed to each other. How is the pkgsrc infrastructure
> > to know that someone won't type "make package" after building an
> > out-of-sync module?
> Implementation seems easy enough: when you type "make package" (or
> pkg_tarup, or any other command that makes a binary package), the
> tools can know exactly what you have installed at that instant. That
> information could be embedded in the binary package, and indeed
> Frederick Bruckman mentioned that binary packages already contain
> "@blddep" information.
The "@blddep" thing is only in current, not yet forced on all users,
and even in current, it's not yet used for much.
At some point, you have to decide, is mission one to build binary
packages, or is it just build binaries? If our *package* system is
supposed to build *packages*, then we have to eliminate some of the
combinations that otherwise work fine, but aren't cooperatively
reusable with other possible packages, and so aren't supportable.
> People who build binary packages for use by others (as opposed to
> building binary packages for their own use) should probably be cautious,
> and restrict themselves to building packages with all the latest
> dependencies. The bulk-build infrastructure can help people who want
> to produce large sets of binary packages whose dependencies are all
> consistent with the latest pkgsrc.
That's not how they're all built now. Even if they were, I think
people would like to be able to install some binary packages, then
build some, then install some more binary packages. If you're going to
say, instead, that the packages only work as a complete, static set,
then why bother embedding dependencies on a specific version at all?
It's actually been suggested that, rather than fixing the
dependencies, it be mandated that packages on ftp.netbsd.org only be
built all-at-once against a release, which seems to come out once a
year or so. I think that would be unfortunate.
> > People who build only from source can play fast and loose at their own
> > risk, but such risk must not be allowed to leak into the way binary
> > packages are managed.
> When you say "binary packages", I think you mean "publicly available (or
> official) binary packages".
> When I say "binary packages", I include packages that I make myself via
> "make package", "make bin-install" or "pkg_tarup".
Ah, but what happens when you get a second computer, or a laptop,
and you think you'd like to build packages on one computer for use
on another? The way the package system has been managed in the past,
you're in for a rude surprise. Sometimes, you can't even reinstall
packages you've made a month ago (that claim to be the latest version)
on the *same* host! That the issue I'm trying to deal with with the
"gratuitious" bumps -- so that the latest version of anything will
work, no matter what path you took to get there.