Re: Bug#2307: xpm4.7 has no Maintainer field
I've moved this from debian-bugs because I don't think having extra
verbiage is going to help the bug report.
>> Yes---as I understand it, the package name should reflect the soname
>> of the shared library (4.7) so we can have multiple versions
>> installed, while the version name reflects the upstream version
>> (3.4g).
>reflect the soname why?
Because the soname represents the version number of the Application
Binary Interface. You must have available a shared library with the
same ABI your program is expecting else bad things can happen. At the
very least, programs might not load. At worst your HD might get
trashed.
>How many versions will be installed, is this required optional, desirable?
In a perfect world, one would never need more than one version of any
library because every package that was ever dependant upon a library
would be updated within minutes of a new library release by the
respective package maintainers.
I'm sure you see the problems with the assumptions inherent in that
statement.
Therefore we must allow for situations where one package depends upon
libwhatever.so.4.6 and another depends upon 4.7---eventually, the
package that depends upon 4.6 should be updated and 4.6 can be done
away with, but do you want to be hampered if it doesn't happen quickly
enough?
>Isn't symlinking enough?
No. A new soname implies a binary incompatability, thus a symlink
will not solve the problem, and in fact is likely to cause problems.
Just check out a heavily updated Microsoft Windows 3.1 setup for the
problems that can be caused by only allowing one version of a
particular dll to exist on a system---you can end up with different
programs having workarounds for bugs in different versions of the dll
such that there is no combination available where all applications
work correctly.
>If you need multiple versions, are shared libraries space savers or
>consumers.?
If you have n programs depending on a library, as long as you only
require n-1 different versions of said library, you have probably
saved space (depending on the exact size of the library and how much
would have been linked into a given program, etc).
Obviously we would like to shoot for a better ratio than n/n-1,
though.
I'd like to reiterate that this is a hedge against a possibility,
rather than the expression of a policy---I don't think anyone _wants_
to have to have more than one version of a library laying (lying?)
around, but it's shortsighted and potentially restrictive to not allow
for the possibility, because we have no way of making sure that every
maintainer whose package depends on a library will be able to make a
timely update to reflect the new library version.
Mike.
--
"I never worry, why should I. It's all gonna fade."
Reply to: