Hi! Just to give some context and background, this started with the discussion of binNMUs and multi-arch [0], related to file conflicts due to the coinstallability of multiple M-A:same instances, and while initially a wild idea to possibly fix that specific case, it seemed to me it was generic enough and which would make other parts of the system easier and more structured.
[0] <http://lists.debian.org/debian-dpkg/2011/09/msg00029.html> On Sat, 2012-07-14 at 09:48:35 +0900, Charles Plessy wrote: > in http://bugs.debian.org/681289, Raphaël proposed that the Changelog and > copyright should be package metadata. A policy proposal (prompted by [1]) which was IMO premature (as usual), that I was planning on bringing up later on to debian-devel before even considering proposing such policy change... Now I guess we'll end up with this being discussed in several places. [1] <http://lists.debian.org/debian-dpkg/2012/07/msg00026.html> > I personally like the idea, but I note > that last time it was introduced on debian-devel, it was not consensual > (http://lists.debian.org/20437.51932.971859.384...@chiark.greenend.org.uk), so > I answer to your proposal on debian-devel to restart the discussion there. Debian usually operates by rough consensus, which means not every one has to agree, as long as mostly everyone does. And as I mentioned in my reply, there didn't appear much convincing arguments in that mail you point to. > As the logic applied to the changelog and copyright files can be applied to > most other files produced by the packager, like NEWS.Debian, it looks like the > trend would be to have them installed in /var/lib/dpkg rather than > /usr/share/doc. I already mentioned this in [2] and [3], I think it only makes sense to consider as metadata machine parseable files, and ones closely related to the packaging system, not any maintainer created files such as ones specific for installation helpers for example. As such NEWS.Debian *might* indeed make some sense to put there too, but not many more if at all, and they would need careful consideration. [2] <http://lists.debian.org/debian-devel/2012/06/msg00314.html> [3] <http://lists.debian.org/debian-devel/2012/06/msg00410.html> > This is somewhat equivalent of a change in the binary package format, as > packages will need to pre-depend on a recent version of dpkg, No, it's not really equivalent, and no, they will not need to Pre-Depend on a recent dpkg, any dpkg version will handle those files as control files automatically, and do the right thing. Also the fact that those files were in «/usr/share/doc/» before means no program can truly rely on them being present as per policy those paths can be removed by the admin. The only new interfaces that I introduced in dpkg 1.16.5 specific to this (dpkg-query --control-list and --control-show) are for users and programs to be able to easily get those files w/o having to rely on the internal database paths. > and programs not getting the metadata through dpkg will need to be > corrected. Also mentioned in [2] and [3]. And just to clarify, when I've been referring to this as metadata, I've not been referring to say a new field in the status file, just as those files as additional files in the db, like the md5sums shipped by packages and generated at build time. > Pushing the logic further, I wonder if that suggests that the Debian binary > package format could be simplified to be a simple tarball with the metadata > in /var/lib/dpkg, instead of the current format with a data and a control > tarballs joined together in the 'ar' format. That would not simplify it at all, in fact it would make it way more complex, not to mention it would require bumping the .deb version format to 3.0. > This would not prevent dpkg to store the metadata somewhere else than > /var/lib/dpkg later, as it would be easy to intercept the files and treat > them appropriately, similar to what is being done with files in > usr/share/doc with multi-arch packages. Also, once using a simple > tarball as binary package, arbitrary files become trivial to extract > quickly, or perhaps even to update (like for translations). This would require to hardcode several path locations in dpkg just to make them generic again internally, which does not make any sense to me. Also dpkg does not currently have any internal knowledge about magic paths, and there's no special handling of multi-arch paths for «/usr/share/doc/». regards, guillem -- 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/20120714070029.ga9...@gaara.hadrons.org
