>
> 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"
<[EMAIL PROTECTED]>, 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, [EMAIL PROTECTED]
#!/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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
