Re: architecture alias and disto rebuild
Bill Allombert <allomber@math.u-bordeaux.fr> writes:
> Hello Debian developers,
>
> Some distributions/people rebuild a lot of Debian packages from Debian
> source while making no change to the source. While this is technically
> a binNMU they seldom bother to bump the version, which lead to two debs
> files with different content (if they are built with a different version
> of gcc, e.g) which somehow break the package version idea and make very
> hard to see it is not the one compiled by Debian.
Maybe dpkg should record the md5sum of the deb of each installed
package to prevent such accidents.
> This is understandable since bumping the version can cause unforeseen
> bugs (though I would like very much a list of package that cannot be
> binNMUed). So I propose a alternate solution:
Look in /var/lib/dpkg/status:
Package: dpkg-dev
Status: install ok installed
Origin: debian
...
The Origin specifies where a package comes from and is taken from the
Release files. Everyone should make sure to put the right information
in there. I don't see any benefit of mangling the same info somewhere
else. Noone will do that any more than they increase versions on
rebuilds.
> If the distro foobar rebuild packages on i386, they could use
> i386foobar as architecture name instead of i386, this way every
> package they rebuild will be clearly marked as such.
That would affect a hell of a lot of things. You would have to change
the dpkg-architecture output for a simple change which in turn is
passed to cinfigure scripts and all hell breaks loose.
Very bad idea.
> Of course, if foobar want to allow regular Debian package to be installed,
> they can just patch dpkg so that it accept both kind of package.
>
> The morale of the story is: since we have now comprehensive plateform
> handling with CPU-SYSTEM, why not go a little farther and add a BUILDER
> field with the suitable logic in dpkg so that it allow to install
> packages from any builder by default ?
A comprehensive CPU-KERNEL-C_ABI system is in the works for multiarch
and it means extra work exponential with the number of fields and
entries. Adding useless, for the sake of dependency and abi cheks,
information in there as well would just blow up the work needed.
Very bad idea.
> Cheers,
MfG
Goswin
Reply to: