Re: Summary: dpkg shared / reference counted files and version match
Hi,
Jakub Wilk wrote:
> How about:
> * Because this the obvious and elegant way of doing things. It makes
> multiarchification easy for packagers, and invisible for uses,
> including those users who don't care about multi-arch (unless they
> rely on paths to the libraries, which they never should do).
I suppose that is a matter of opinion. The need to make sure files
that are not arch-qualified match at least functionally between
architectures is subtle and not very easy. Tying package versions in
different architectures, which makes dependency chains more rigid, is
not invisible to users.
However, in the special case of header files (which are text files
that almost never vary between architectures), I agree that it would
be nice to be able to preserve the simplicity of the current approach
from the packager's perspective.
[...]
> By allowing co-installation of two different versions of the same
> package, you are opening a can of worms, regardless of whether
> refcnt is implemented or not.
Could you elaborate on this?
As long as dependencies are accurate, I don't see how allowing
co-installation of the same package for two different architectures at
different versions is any more complicated than pinned to the same
version.
[...]
>> * Once implemented, this “feature” cannot be taken out, *ever*.
>
> This boils down to “I don't like it”. If it's useful, why would one
> consider taking it out?
After trying out the approach without refcounted files for a while, it
would be painless for the project to say "This is too much trouble"
and add refcounting. By contrast, it is very painful to move in the
other direction. I think that is worth taking into account.
[...]
>> Proposed solution
[...]
> This will require changes to the Policy, to which I (and hopefully
> other developers) will object.
Last time I checked, multiarch is not in policy yet.
> Please don't throw into the mud work of individual developers
> (including me) who already converted their packages to multi-arch.
I agree that the extra work of removing "multi-arch: same" for
existing -dev packages that have been converted is a major downside.
And on the other hand, the need throughout Debian infrastructure to
support the very fragile refcount approach would be a downside to that
approach.
This is not so one-sided as you seem to be suggesting.
Jonathan
who wishes he knew of a fifth approach without the downsides of the
others proposed so far :)
Reply to: