Re: Summary: dpkg shared / reference counted files and version match

[Thorsten Glaser <tg@mirbsd.de>]

Jakub Wilk dixit:

>> * binNMUs for the same version cannot be co-installed anyway as their
>> changelogs differ.
>> ↓
>> That could be “fixed” by using the same email address and a hardcoded
>> date, or not including the binNMU entry at all, or moving that entry to a new
>> field, etc. All of which seem like ugly hacks, or a possible loss of
>> information.
>
> http://lists.debian.org/debian-devel/2012/02/msg00316.html

Hrm. But where is the line between files that are the same and files
that differ in, for example, a binNMU?

Worse: think of using M-A as porting toolkit. Say, you’re working on
arm64 and want to cross-compile using M-A (for example because the
current¹ approach is deprecated – already, dpkg-cross needs a flag
to convert libc6-dev as it’s M-A). But some package does not build
unmodified, so the target architecture has it uploaded to d-ports.org
“unreleased” with local changes.

With Guillem’s refusal of file sharing, this would work as-is, but
not otherwise because of differences between the package versions.
(You could build, say, eglibc_2.13-27+arm64.1.dsc, locally for your
host system and install it, but that’s just ouch.) Wasn’t M-A intended
to be a porting tool (among others like a biarch/triarch replacement)
just for this purpose?

> Please don't throw into the mud work of individual developers (including me)

That’s what I thought at first when I read about this, too (except
I’m not affected). But Guillem does seem to have a point.

What do our “new architecture upbringers” (e.g. armhf people) say?
(Maybe take powerpcspe, as it seems to require more changed packages.)

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
						-- Edward Burr