Bill Allombert <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]