Subject: Re: make update hell
To: Pavel Cahyna <email@example.com>
From: Jeremy C. Reed <firstname.lastname@example.org>
Date: 10/07/2004 09:02:38
On Thu, 7 Oct 2004, Pavel Cahyna wrote:
> > One solution (but has not been done yet) is to take advantage of the
> > information already recorded by pkgsrc. We have the list of libraries
> > provided and required in the +BUILD_INFO files (see PROVIDES= and
> > REQUIRES=). Maybe we can add some rules that check this information on
> > installs and deinstalls and upgrades.
In addition, this would especially help when PKGREVISIONS are accidently
not (manually) bumped, because the SONAME (or library name) matching can
be an automated check. ("Sorry you can't replace this package because bar
needs libfoo.4.so and the new libfoo package provides libfoo.5.so.")
I use packages on systems that don't have pkgsrc building. I have a custom
pkg_install tool that I use to upgrade packages in place (by overwriting).
Also regular pkg_add also offers an upgrade option (by pkg_delete first
but packages needing that package are not deleted). Being able to have a
second check for library names would be great.
> The intent is to use this infomation to tell if a "make replace" is safe
> or not? It would be a step forward, but it still would not enable to have
> multiple versions of a library installed in parallel, no? So if "make
> replace" decided that it would be unsafe, nothing would break, but you
> still would have no way to proceed except rebuilding all the depending
> packages. Is this correct?
Using pkgsrc in the norml way, yes.
> I saw a thread recently on tech-pkg@ that discusses something like
> embedding a version number in package name, That would probably help in
> this situation.
In a few cases, this is already done. But even they may have potential
issues when they are upgraded.
And patching packages to train them to install in different locations can
be a lot of work. For example, simply changing the library name can be
easy, but what about numerous headers and numerous other shared files?
They may need to be renamed or moved to their own directories to not
conflict. This is could be a lot of work for just one single package
because software may have to be patched a lot to know where its data is
stored and to make sure it doesn't use other date.
Pkgsrc also provides a system called pkgviews. You can install packages
many times -- each is stored to its own directory. I have used it some and
it appears to work fine. Not all packages are available for pkgviews yet
but many are. Give pkgsrc's pkgviews a try.
Jeremy C. Reed
technical support & remote administration