Sorry for the late reply, I was waiting for the current version to enter testing before doing anything else.
On Fri, 13 Jul 2012, Raphaël Hertzog wrote: > Package: base-files > Version: 6.11 > Severity: wishlist > > /etc/os-release can now provide everything that /etc/dpkg/origins/default > does and thus I would like to deprecate /etc/dpkg/origins/* (I filed > #681474 against libdpkg-perl to track this). > > However /etc/dpkg/origins/* has the benefit of keeping the information > of the parent distributions which /etc/os-release alone can't do. > > After discussion with the systemd upstream maintainers, we came to the > conclusion that the best approach would be to store those files > in /etc/os-release.d/ and /etc/os-release itself could be a symlink > to the right file in /etc/os-release.d/ (hence /etc/os-release.d/debian) > for Debian. > > The upstream documentation of /etc/os-release explicitly allows > /etc/os-release to be a symlink, see > http://www.freedesktop.org/software/systemd/man/os-release.html > > Thus I would like base-files: > - to ship /etc/os-release.d/debian > - to ship /etc/os-release as a symlink to the former That would be easy indeed. However: What happens when a conffile is replaced by a symlink to a conffile? Does dpkg handle it gracefully or does it break horribly? My fear here is that we create some kind of "unsolvable bug" like, for example, #679356. Also: What would happen if the move is made at the same time that the default conffile is modified? I'm thinking about #681480 reported by you as well. > - to make it easy to add supplementary files in /etc/os-release.d/ > and to update the symlink (i.e. reuse the VENDORFILE variable that you > already have) for derivatives By "easy" I assume you mean "easy for whoever wants to modify the package for derived distros". Yes, that would be easy as well. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
