At 19:26 Uhr -0500 01.02.2002, David R. Morrison wrote:
>Yes, the installation order business bothered me. One possibility is
>to force people to install in the correct order, by this trick:
>
>Package: db1
>
>***
>
>Package: db2
>Replaces: db1
>
>***
>
>Package: db3
>Replaces: db1, db2
>
>***
>
On Friday, February 1, 2002, at 07:19 , Max Horn wrote:
> That sums it up pretty well, indeed.
>
> The only potentially trouble spot is that the order in which (in your
> example) db3 and db4 are installed affects to which the db.dylib
> symlink points. If a package has to link against a partic
Yes, the installation order business bothered me. One possibility is
to force people to install in the correct order, by this trick:
Package: db1
***
Package: db2
Replaces: db1
***
Package: db3
Replaces: db1, db2
***
This way, if you try to install db2 after db3, you will be told that you
That sums it up pretty well, indeed.
The only potentially trouble spot is that the order in which (in your
example) db3 and db4 are installed affects to which the db.dylib
symlink points. If a package has to link against a particular
version, that could generate problems. Alas, in such cases,
I've been studying the Debian policy about shared libraries, and I think
I understand their strategy much better now.
It has several components. First, the libraries themselves are separated
from the headers -- you have to have two packages per program. (Well,
actually three in many cases, beca
At 17:31 Uhr -0600 01.02.2002, Ken Williams wrote:
>On Thursday, January 31, 2002, at 11:28 AM, Max Horn wrote:
>>Achieving that is a quite involved task indeed, since it means you
>>have to keep parts of a package around (like libtiff.3.dylib), enve
>>though the rest of the package is removed,
On Thursday, January 31, 2002, at 11:28 AM, Max Horn wrote:
> Achieving that is a quite involved task indeed, since it means you have
> to keep parts of a package around (like libtiff.3.dylib), enve though
> the rest of the package is removed, creating "orphaned" files that
> nobody owns anymo
On Thursday, January 31, 2002, at 05:28 , Max Horn wrote:
> Of course that is suboptimal. In this situation, the only way for the
> user to update would be to first remove the old versions of the
> dependant stuff, then update the lib, then reinstall the removed stuff.
> Yucky.
Yes, I agree.
At 13:58 Uhr -0500 31.01.2002, David R. Morrison wrote:
>Thanks for the explanation, Max. It's something that I kinda knew, but
>had forgotten.
>
>I haven't ever used Debian/Linux, but what I am hoping will happen after
>we get this going is this: if I install a new version of a library,
>dpkg w
Thanks for the explanation, Max. It's something that I kinda knew, but
had forgotten.
I haven't ever used Debian/Linux, but what I am hoping will happen after
we get this going is this: if I install a new version of a library,
dpkg will automatically recompile all of the guys that depend on it.
At 11:37 Uhr -0500 30.01.2002, David R. Morrison wrote:
>I'll take over as the new libpng maintainer (from chrisp). I made a fink
>package for the latest upstream version. However, I have not put it on
>CVS, because the major version number has changed and if you install the
>new one, you will b
11 matches
Mail list logo
