Jonathan Nieder <jrnie...@gmail.com> writes:
> 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.
1) It is dead easy:
- If they are in /usr/share then you already decided they are fit for
all archs.
- If they (potentially) aren't in /usr/share then you already decided
they aren't fit for all archs.
You might have to rething that decision but the decision is not
completly something multiarch adds to the table. It already exists, just
was never enforced like this.
[scripts in /usr/bin and include files are an exception but the former
must not be in library packages and the later is easy to decide]
2) Reference counting files or spliting packages doesn't change the
decision:
- If the file is fit for all archs then you can let the reference counting
take care of it or you have to move the file into a -common package.
- If the file isn't fit for all archs then you need to arch qualify it.
As such it is irelevant to the problem at hand.
> 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.
Esspecially for the cases where you would have a -dev-common package
with handfull of headers and a -dev package with only the .so link
left. On file packages seem a bit excessive. Just saying.
> [...]
>> 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.
And said dependencies are already completly neccessary for the mono-arch
case other than the case of messing up the MA:same/foreign field.
What multi-arch adds though is that packages have to be carefull about
file formats. An MA:same package could require a different file format
for a common file for different versions (and thus archs). Some MA:same
package would have to Break with themself across all archs to ensure all
archs upgrade to a new format together.
Did you mean that?
> [...]
>>> * 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 :)
All this fear about compression formats changing or being unable to
decide when it is save to refcount a file are a bit stupid. Just because
you have refcounting doesn't mean you can't split packages or arch
qualify files. That will still be an option. The refcounting was never a
solve all solution but a way to make the trivial cases not a total pain.
- allow refcounting
- use uncompressed files for Changelog, copyright, README, NEWS,...
- fix the binNMU issue with Changelogs differing (make them metadata?)
- split package that have/want compressed files
- if you cant ensure / doubt files are identical split the package or
arch qualify the files
What it comes down to is this: Use refcounting for the trivial cases.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obt5cmx4.fsf@frosties.localnet
