On Mon, 29 Oct 2012, Jonathan Nieder wrote: > Raphael Hertzog wrote: > > > In both cases the purpose of the file is to provide identification > > information about the OS. > > Identification for what purpose? So I know which programmer to > complain to when running into compatibility bugs, like the HTTP > User-Agent field? For display and theming? To distinguish between > package managers? To help automatic bug reporting tools? To make > sure my programs present subtly different bugs on each system, like > the ACPI _OSI method?
Surely you don't have to invent X ways to identify the OS just because you want to identify it in different contexts? Using a single source is just a better design that avoids mistakes where /etc/dpkg/origins/default says Debian and /etc/os-release says Mint (or similar, it's just an example). > os-release is a very nice way to make sure vendor scripts that want to > rely on details about an OS (or even to just collect statistics) do > not need to separately check for /etc/debian_version, > /etc/redhat_release, etc, but I don't see what it has to do with dpkg. dpkg uses /etc/dpkg/origins/default to find out the name of the current vendor (and possibily embed it in the generated .deb at some point) and to adjust dpkg-dev's behaviour at build-time. It also uses the parent relationship for the latter purpose. Both information are already available in /etc/os-release as ID and ID_LIKE. Guillem said that it was counter-productive in case like Fink where we would not want to use ID=macosx. This could be dealt with a new DPKG_VENDOR variable that would override ID for the specific usage of dpkg when there's such a conflict. The other remaining information (Vendor-URL, Bugs) are provided by HOME_URL and BUG_REPORT_URL. Why duplicate the information at the dpkg level when this is clearly system-wide vendor information? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
