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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive:
http://lists.debian.org/[email protected]
