[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: svgalib-dummy again

> Now that svgalib seems orphaned, allow me to come up with this topic
> again... But first a brief summary of the history and the problems:

Well, nearly orphaned. I finally got an answer from "Andy Mortimer"
<madr@globalnet.co.uk>, who currently is the one interested in
being the maintainer. I did this as I wanted to make a non-maintainer
release of svgalib for libc6 (and Andy gave his OK for me to do so,
planned to release svgalib1g tonight, or tomorrow).

> svgalib-dummy is a dummy replacement for svgalib
> dpkg's current dependency mechanism doesn't allow it to be a
> substitute for svgalib, because that is a shared lib and so all
> dependencies on it are versioned dependencies (coming from the .shlibs
> file).

Well, more to the point: when package foo "Depends" on a particular version
of package bar, dpkg ignores all packages that provides: bar.
(It'll only look at the exact package bar, and it's version).

> I now see two solution for this problem:
>  1) dpkg's dependency handling could be extended so that it knows
>     about versioned Provides:. Then svgalib-dummy could provide
>     "svgalib1 (>= 1:1.2.10-2)" or something similar, and a dependency
>     "svgalib1 (>= 1:1.2.10-1") could be satisfied by this.
>     Not only that this is the most elegant way, it also solves another
>     potential problem:
>     The problem with versioned dependencies doesn't only hit
>     svgalib-dummy, which wants to replace a shared lib, it will also
>     effectively make replacements of any shlib package impossible...

Well, it isn't the library stuff that goes wrong, it's the specific versions
that cause dpkg to ignore the Provides: packages.

>     Just imagine we sometime want to rename a shared lib, or replace
>     it by another, improved package. This won't be possible without
>     rebuilding the *depending* packages, because providing a shared
>     lib isn't possible...

Only if the *dpending* packages depends: on a particular version of the
shared lib package. Usually, this isn't the case (the soname of the
library is encoded in the package name, so a package could just depends:
"libfoo272", with 272 the soname of libfoo. But yes, with the current
shlibs files, they will always depend on a particular version of the
library, and it will always go wrong.

>  2) A not-so-nice solution would be to change the .shlibs files of
>     both, svgalib and svgalib-dummy, so that they read
>       libvga        1   svgalib1 (>= 1:1.2.10-4) | svgalib-dummy1
>       libvgagl      1   svgalib1 (>= 1:1.2.10-4) | svgalib-dummy1

Well, this at least woudn't hurt, I guess. Unless anyone objects against
this, I'll add this to the svgalib1g I'll upload tonight/tomorrow.

>     The drawback is that all packages depending on svgalib must be
>     rebuilt with an updated version of svgalib to get in this change.

They have to be rebuilt for libc6 anyway. So that's no problem.

>     This could be handled by first announcing here that those packages
>     should be rebuilt, and if no uploads follow in some reasonable
>     amout of time, I could report bugs against those packages.

Well, don't bother. Other people are already planning to do something
similar with old libc5 packages, you'd just be repeating them.

> So, what method do you prefer? Or do you have better ideas? How hard
> would it be to implement versioned Provides: in dpkg? Or are there
> other reasons not to implement it? Is solution 2) too kludgy?

I strongly prefer method 1. I really think dpkg should be improved,
but as that doesn't seem to happen any time soon, I don't think
method 2 will hurt in the mean time. Anyone else see any problems
with method 2?

joost witteveen, joostje@debian.org
#!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: