On Sun, 2012-10-28 at 21:04:31 +0100, Raphael Hertzog wrote: > On Sat, 27 Oct 2012, Guillem Jover wrote: > > Control: tag -1 wontfix > > *shrug* > > I filed it because I did not found the time to implement it in a > reasonable delay. But I might still want to implement it at some point.
Well, obviously, I object. It was not meant as “I will not fix it”, it was meant as “I don't think this has to be implemented, at all”. > > On Fri, 2012-07-13 at 15:44:22 +0200, Raphael Hertzog wrote: > > > To be able to retrieve information from all the parents, the various > > > os-release files can be stored in /etc/os-release.d/<id> and > > > /etc/os-release > > > could become a symlink. > > > > I doubt this will be done by other distributions anyway. > > Our derivatives did it for /etc/dpkg/origins and I don't see why they > would not follow this as well. For the same reason there's all those distributions in the first place, if everybody agreed on how to do things there would be no need for so many distributions, or operating systems. There's distributions that do not even agree on “basic” stuff like the FHS, or implement LSB support, for example (and I think that's fine). Also because due to the provenance of this “standard” there's systems, I'd say at least most non-Linux ones, that I have a hard time seeing them adopting it (again the FHS applies here too, or some other fd.o specs). > > > Dpkg::Vendor should thus be updated to be able to use those (cross-distro > > > standardized) > > > > I guess by “cross-distro standardized” you mean unilateral systemd-Linux > > specific “standard”, because I don't see non-Linux systems adopting this, > > not even all GNU/Linux distros, and certainly not for something like > > dpkg, which would imply deploying a generic file only for dpkg use. And > > in that case the dpkg origin files would need to be suppored anyway, > > which means that supporting os-release is pointless. > > I don't see why dpkg origin files would have to be supported indefinitely. > We can deprecate them just like any other feature and ask people to use > /etc/os-release & /etc/os-release.d/. Other features do not generally affect or touch the underlying system, they are confined to the dpkg subsystem. Requiring for distributions or other operating systems to add a generic purpose file just for dpkg is way more difficult (think corporate requirements, or system policies, for example), than requring a file under a dpkg namespace on the filesystem. > You argumentation does not hold. Why would it be better to deploy a > dpkg-specific file over a generic file even if dpkg is the only software > making use of that generic file? > > You're free to not like systemd, Loennart Poettering, or both. But in this > specific case, I find this standardization effort a good idea and I don't > see much downsides in adopting it. For starters, as Jonathan has mentioned, they serve completely different purposes, one states what's the current OS, the other what's the origin of *dpkg* and the stuff it manages. Mixing them is a terrible idea. As an example, in the very hypothetical case that Mac OS X or Solaris started deploying that file, other dpkg based distributions on top of those systems would be unable to be distinguished. There would also need to be a mapping between field names for the different files, as there's current existing users for this stuff, and new fields can be added arbitrarily on both types of files, so that alone would be a mess. Also the origin files have always been an interface by themselves, so not every user is going to be using the command, issuing warnings is not going to work there. And I don't really see a problem if most or even all (!?) systems end up adopting that spec, that'd be certainly better than the myriad of foo-release and similar files, but that has nothing to do with my objection in this specific context. > > This is the equivalent of wanting to add support for lsb_release... > > Except lsb_release is a command line interface and it's not always > installed. /etc/os-release is a file with a defined format that's always > going to be there on Debian systems since base-files installs it. There's also the lsb-release file. And, if dpkg has to start requiring external files, it could as well just require the presence of either lsb-release or lsb_release, which would still be a terrible idea (more so because these are *Linux* Standard Base stuff...). And again, dpkg *is* and *has* always been used beyond Debian systems or derivatives. I also completely fail to see the point of a dpkg specific interface to a general purpose file like os-release. guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
