Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Sat, 9 Jun 2007 11:24:08 -0500, Steve Greenland [EMAIL PROTECTED] said: On 09-Jun-07, 04:30 (CDT), Petter Reinholdtsen [EMAIL PROTECTED] wrote: My point is that it is useful to know what major release of Debian a machine is using, My point is the only reliable way to determine that is via /etc/apt/sources and /etc/apt/preferences, not to mention /var/lib/dpkg/status (because packages might be on hold). You are assuming that the contents of /etc/apt/sources and /etc/apt/preferences are fairly static. That is an asumptio0n that does not hold true at least for my laptop, where the sources and preferences change a log when I travel (which is fairly often). Parsing today's sources would lead you to assume I only do security up0dates, and would have no bearing on the versions of packages on my system (which come from local Sid partial mirror, not in my sources.list file today). manoj -- Don't get married. Find a woman you hate and buy her a house. anon Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
[Steve Greenland] Still pointless, because there is basically no reliable connection between the contents of /etc/debian_version and what packages are installed. You seem to still discuss this issue as related to making decisions on package behavior. That is not the point I am trying to make, and in that frame I understand why you fail to see the point. My point is that it is useful to know what major release of Debian a machine is using, and for that to work it is better to store that information in a simple package which can be modified whenever the release information changes, and to make sure no other information is coded in that package (so the version info should be moved out of the base-files package). If we had that kind of information, I suspect we could make better informed decisions on security support for different major releases. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On 09-Jun-07, 04:30 (CDT), Petter Reinholdtsen [EMAIL PROTECTED] wrote: My point is that it is useful to know what major release of Debian a machine is using, My point is the only reliable way to determine that is via /etc/apt/sources and /etc/apt/preferences, not to mention /var/lib/dpkg/status (because packages might be on hold). Yes, many systems don't mix-n-match, and are pure etch or whatever. The contents of /etc/debian_release doesn't, and can't, tell you that, no matter how it's packaged. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
[Javier Fernández-Sanguino Peña] Bastille uses it to distinguish releases. There seems to be others: Using /etc/debian_version is not a good idea. I know this because I tried to let popularity-contest collect its content to see what version of Debian were in use. Here is the list of values from 2004-05-13: Release: Debian 1 Release: testing/unstable3670 Release: sid1 Release: stable/testing 3 Release: unstable 8 Release: testing/sarge 1 Release: Testing/Kriller1 Release: unknown 1323 Release: 3.0-bunk-1 1 Release: Woody 1 Release: special1 Release: sarge 3 Release: woody 1 Release: 3.12 Release: 3.0 53 Release: unstable/experimental 1 Release: debian-sid-i3861 Release: 2.21 Release: unstable/testing 1 Release: testing2 Release: Sarge 1 Release:3 As you can see, the values varies widely. Based on this, we decided it was useless, and stopped collecting the value. When that is said, I believe it is a good idea to split the Debian version into its own package like RedHat do it, to make sure the version can be updated without updating all the other files in base-files. This would make it possible to fix the version in testing without having to fix the version of all the other files in the base-files package in /etc/. The redhat-release package contain these files, and it is updated for every minor release of redhat, making it easy to track the patch level on redhat machines: [EMAIL PROTECTED] ~ $ rpm -qf /etc/redhat-release redhat-release-5Client-5.0.0.9 [EMAIL PROTECTED] ~ $ rpm -ql redhat-release /etc/issue /etc/issue.net /etc/pki/rpm-gpg /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-test /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-auxiliary /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-former /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release /etc/redhat-release /etc/yum.repos.d/rhel-debuginfo.repo /usr/share/doc/redhat-release-5Client /usr/share/doc/redhat-release-5Client/EULA /usr/share/doc/redhat-release-5Client/GPL /usr/share/doc/redhat-release-5Client/autorun-template /usr/share/eula/eula.de_DE /usr/share/eula/eula.en_US /usr/share/eula/eula.es_ES /usr/share/eula/eula.fr_FR /usr/share/eula/eula.it_IT /usr/share/eula/eula.ja_JP /usr/share/eula/eula.ko_KR /usr/share/eula/eula.pt_BR /usr/share/eula/eula.ru_RU /usr/share/eula/eula.zh_CN /usr/share/firstboot/modules/eula.py /usr/share/firstboot/modules/eula.pyc /usr/share/firstboot/modules/eula.pyo Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, 8 Jun 2007, Petter Reinholdtsen wrote: [EMAIL PROTECTED] ~ $ rpm -qf /etc/redhat-release redhat-release-5Client-5.0.0.9 [EMAIL PROTECTED] ~ $ rpm -ql redhat-release /etc/issue /etc/issue.net /etc/pki/rpm-gpg /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-test /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-auxiliary /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-former /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release /etc/redhat-release ... While I like your idea in principle I wonder whether it is really reasonable to put this information into a conffile. Everybody can change this to something else. Isn't it better to implement a /usr/bin/debian-release that contains an option to get the real version number that is hard coded anywhere if /etc/debian_version was changed? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Andreas Tille [EMAIL PROTECTED] writes: Everybody can change this to something else. Isn't it better to implement a /usr/bin/debian-release that contains an option to get the real version number that is hard coded anywhere if /etc/debian_version was changed? Why not just use lsb_release(1)? [EMAIL PROTECTED]:~$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux testing (etch) Release:testing Codename: etch [EMAIL PROTECTED]:~$ But I have no idea where these information come from. According to /etc/debian_version I'm running'lenny/sid'. [... less /usr/bin/lsb_release ... ] Hmmm, lsb_release seems to parse 'apt-cache policy' and hardcodes the 'testing is etch' connection. //Makholm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 08, 2007 at 09:33:26AM +, Peter Makholm wrote: But I have no idea where these information come from. According to /etc/debian_version I'm running'lenny/sid'. This was discussed previously in the thread... Hmmm, lsb_release seems to parse 'apt-cache policy' and hardcodes the 'testing is etch' connection. And this is an ugly hack since it forces the *program* to be changed for each release instead of the *data* which leads to #425646 and similar bugs. Regards Javier signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On 08-Jun-07, 03:35 (CDT), Petter Reinholdtsen [EMAIL PROTECTED] wrote: When that is said, I believe it is a good idea to split the Debian version into its own package like RedHat do it, to make sure the version can be updated without updating all the other files in base-files. This would make it possible to fix the version in testing without having to fix the version of all the other files in the base-files package in /etc/. Still pointless, because there is basically no reliable connection between the contents of /etc/debian_version and what packages are installed. Yes, in some controlled environments, it may be useful. If you have one of those environments, then you *know* what the possible values are and what they mean. But in general, it's not reliable. The good news is that it's not necessary, either. Just Depend: on the package versions you need, and stop worrying about it. Steve PS How come my unstable system says lenny/sid and my etch systems say 4.0? Is someone deliberately trying to make it impossible to parse? Perhaps as a not-so-subtle way of saying don't use this from code? -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
[Andreas Tille] While I like your idea in principle I wonder whether it is really reasonable to put this information into a conffile. Not sure about that. My main point is that the content of /etc/debian_version should be changed independently of the changes done to base-files, and thus be split out from that package. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Lennart Sorensen wrote: For the kind of cash the enterprise vendors tend to charge, yes actually now that you ask, I think I can expect them to figure out dependancies and making proper packages. ... by making reasonable assumptions about what is on the system based on a standard install of $version of $distribution. Asking enterprise vendors to support your (customised, hacked-up, non-standard) OS install is, um, unlikely. Unless you're paying them enough for them to completely mirror your environment in the dev lab and certify their product on *your* particular combination of software. (Of course, most people running mixed-version Debian systems are unlikely to be buying enterprise software like Oracle. g) (This is drifting off from my original question: what simple test(s) for uniqueness can I use to determine which version of which distribution I'm on? FWIW, it seems that for my purposes, the contents of /etc/debian_version and the full version+release string from the base-files package are sufficiently unique.) -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On 05-Jun-07, 08:37 (CDT), Kris Deugau [EMAIL PROTECTED] wrote: Lennart Sorensen wrote: For the kind of cash the enterprise vendors tend to charge, yes actually now that you ask, I think I can expect them to figure out dependancies and making proper packages. ... by making reasonable assumptions about what is on the system based on a standard install of $version of $distribution. Asking enterprise vendors to support your (customised, hacked-up, non-standard) OS install is, um, unlikely. No, I'd ask them to build correct packages for the current stable version, e.g. etch. If they've got their dependencies correct, I should be able to install packages from other releases without too much anguish. Of course, if I have problem, I shouldn't be surprised to hear we can't duplicate it on our pure etch system... Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Tue, Jun 05, 2007 at 09:37:58AM -0400, Kris Deugau wrote: ... by making reasonable assumptions about what is on the system based on a standard install of $version of $distribution. Well too many seem to assume that you are running some version of redhat, and that redhat equals linux and there are no reasons to consider anything else. Asking enterprise vendors to support your (customised, hacked-up, non-standard) OS install is, um, unlikely. Unless you're paying them enough for them to completely mirror your environment in the dev lab and certify their product on *your* particular combination of software. (Of course, most people running mixed-version Debian systems are unlikely to be buying enterprise software like Oracle. g) Sure. If I say I run debian sarge, and I install the .deb for debian sarge, it should work, unless I have mixed in stuff that isn't part of sarge, in which case that would be my problem. So yes as long as they provide a proper .deb targeted at sarge, that would be fine. Of course Etch would be more interesting than Sarge by now. (This is drifting off from my original question: what simple test(s) for uniqueness can I use to determine which version of which distribution I'm on? FWIW, it seems that for my purposes, the contents of /etc/debian_version and the full version+release string from the base-files package are sufficiently unique.) Certainly the /etc/debian_version is what I would rely on. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Mon, Jun 04, 2007 at 04:16:29PM -0400, Lennart Sorensen wrote: On Sun, Jun 03, 2007 at 11:16:08PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: Think about Enterprise (non-free) software like Oracle, HP Openview, Tivoli, Remedy... Do you expect vendors of this software to understand^Wimplement package management based dependencies for *all* Linux distributions? LSB tries to simplify the Linux environment for such software. Lsb_release is defined as the an answer to the question which distribution am I running in and which release is it? For the kind of cash the enterprise vendors tend to charge, yes actually now that you ask, I think I can expect them to figure out dependancies and making proper packages. Opera seems to manage, and they are giving away their non-free software for free. Managing to package and test your code on most major distributions is actually a good way to ensure the programmers didn't go do something stupid that is going to cause problems later. I'm afraid you're comparing apples and oranges here. Opera is a rather small product and codebase when compared to the products of any of the Enterprise software players I placed above. In some of the examples I placed above a software release of a given version of their product is made up of 4-5 CDs of binary software. Opera is, what, a 4-7 MB download? Believe me, people running Linux and using this kind of software will, in most cases, not get a package integrated into their $distribution package's management system but an installation program from the vendor that works by its own rules. The funny thing is, some of these installation systems actually installs a package management system of itself which is completely unrelated to the system's. That's the case of HP's depots, the package management system for HP-UX, which is also used in software like HP Openview when installed in other operating systems too (at least I know of Sun's Solaris and IBM's AIX) And, even funnier, those that *do* provide packages (RPM packages in all the cases I've stumbled upon) don't setup proper dependencies so even if they install fine on a system they were not prepared for (think SuSE vs. RedHat) they just don't run. Vendors just use the package management system as an archiver (a 'bigger' tar.gz or zip file if you will). Many organisations I've worked with in Spain (including Telcos and Banks) pay large amounts of cash in licenses to these (overseas) software vendors and no, they are not pushing them to get packages for their favorite distribution. They just push them to make it *works* (i.e. run and be supported) in $distribution and are not always succesful (which means they have to install the vendor software in the official/supported/approved platforms the vendor has decided upon). Long-term, the fact that the software was installed using a .deb, .rpm, an installation script or a tar.gz is not important at all. Having the vendor support your environment is. Regards Javier signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Frankly, helping vendors of non-free software lies far below the ability to provide our users the option to do partial upgrades, apt-pinning, etc. If we are not going to impact the utility to the users; I am indifferent to adding things to help non-free software vendors. Apart from the fact that the above may very well explain why Debian is not used in all places where it should be used, I don't really see what hurts in having a lenny system where lsb_release -n reports Debian GNU/Linux 4.1beta (lenny) or something similarat least *not* Debian GNU/Linux 4.0r0 (etch). signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Sun, Jun 03, 2007 at 05:28:24PM -0500, Manoj Srivastava wrote: Frankly, helping vendors of non-free software lies far below the ability to provide our users the option to do partial upgrades, apt-pinning, etc. How does /etc/debian_version of lsb_release hinder that? I'm not suggesting we ditch partial upgrades or apt-pinning. Please reread my email. If we are not going to impact the utility to the users; I am indifferent to adding things to help non-free software vendors. How are we going to impact our users? I really don't understand your email. Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Sun, Jun 03, 2007 at 11:16:08PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: Think about Enterprise (non-free) software like Oracle, HP Openview, Tivoli, Remedy... Do you expect vendors of this software to understand^Wimplement package management based dependencies for *all* Linux distributions? LSB tries to simplify the Linux environment for such software. Lsb_release is defined as the an answer to the question which distribution am I running in and which release is it? For the kind of cash the enterprise vendors tend to charge, yes actually now that you ask, I think I can expect them to figure out dependancies and making proper packages. Opera seems to manage, and they are giving away their non-free software for free. Managing to package and test your code on most major distributions is actually a good way to ensure the programmers didn't go do something stupid that is going to cause problems later. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 01, 2007 at 07:14:16PM +0200, Santiago Vila wrote: On Fri, 1 Jun 2007, Javier Fernández-Sanguino Peña wrote: We are not telling the user, we are telling *programs* what environment they are in. That's the fundamental mistake I see here: We should not be telling programs what release they are running to begin with. We do not try to make packages to work under the assumption that they will run on a sarge system or an etch system. Instead, we try to make them work as far as their dependencies are met. Since when do programs == package? You don't seem to understand that I'm talking in a generic way about software. Actually, I'm mainly talking about software which is *not* part of the package management system [1]. I agree with you that packages *in* Debian should not use /etc/debian_version or lsb_release, but what of software (not packages) *outside* Debian. Think about Enterprise (non-free) software like Oracle, HP Openview, Tivoli, Remedy... Do you expect vendors of this software to understand^Wimplement package management based dependencies for *all* Linux distributions? LSB tries to simplify the Linux environment for such software. Lsb_release is defined as the an answer to the question which distribution am I running in and which release is it? Developers of such software, taking the LSB as a reference, can use lsb_release to determine where they are in. However, if we lie [2] to these tools we are actually making this software break. Lsb_release should *always* provide correct information, I've sent some patches already (and a new bug with a patch) to try to fix the current issues, but without /etc/debian_version having correct contents throughout *all* the release in our non-releases (sid, testing) it might be the case that it will provide incorrect information in an unpredicable timeframe. I.e. the time between your upload of base-files for a release that is not yet so and between your upload of a new 'testing/unstable' base-files package. Let's look back: For the 'etch' release this was: - From 2006-10-28 (base-files-4) to 2007-04-03 (base-files-4.0) in sid -- Over 5 months - From 2006-11-10 to 2007-04-10 in testing -- Exactly 5 months For the 'sarge' release this was: - From 2004-07-26 (base-files-3.1) to 2005-06-06 (base-files-3.1.3) in sid -- Almost 1 YEAR What will happen will 'lenny'? Can external software rely on being able to properly determine which distribution is it running it without digging into the package management information and deriving it from there? I hope I've made my point clear. Regards Javier [1] I brought up the fact that some of the sofware in *our* package management system uses /etc/debian_version because you thought the instances of packages using that was zero, not to imply that every package should. [2] We lie to it when lsb_release fails to provide the correct information of what system the program is running in. This happens in a number of situations as I already stated including when we are approaching a release and the contents of /etc/debian_version are bogus (in sid and testing). signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Sun, 2007-06-03 at 23:16 +0200, Javier Fernández-Sanguino Peña wrote: On Fri, Jun 01, 2007 at 07:14:16PM +0200, Santiago Vila wrote: On Fri, 1 Jun 2007, Javier Fernández-Sanguino Peña wrote: We are not telling the user, we are telling *programs* what environment they are in. That's the fundamental mistake I see here: We should not be telling programs what release they are running to begin with. We do not try to make packages to work under the assumption that they will run on a sarge system or an etch system. Instead, we try to make them work as far as their dependencies are met. Since when do programs == package? You don't seem to understand that I'm talking in a generic way about software. Actually, I'm mainly talking about software which is *not* part of the package management system [1]. I agree with you that packages *in* Debian should not use /etc/debian_version or lsb_release, but what of software (not packages) *outside* Debian. Think about Enterprise (non-free) software like Oracle, HP Openview, Tivoli, Remedy... Do you expect vendors of this software to understand^Wimplement package management based dependencies for *all* Linux distributions? LSB tries to simplify the Linux environment for such software. Lsb_release is defined as the an answer to the question which distribution am I running in and which release is it? snip LSB tries to simplify the Linux environment by allowing independent software vendors to specify dependency on standardised features (LSB-foo version x.y) and not on particular releases or packages within them. However, if one wants technical support from an ISV, it is probably necessary to install a specific stable release and to avoid using packages from a mixture of releases (or backports). In this case, lsb_release will provide correct information. In other cases there's no right answer. Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon signature.asc Description: This is a digitally signed message part
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Sun, 3 Jun 2007 23:16:08 +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] said: Since when do programs == package? You don't seem to understand that I'm talking in a generic way about software. Actually, I'm mainly talking about software which is *not* part of the package management system [1]. I agree with you that packages *in* Debian should not use /etc/debian_version or lsb_release, but what of software (not packages) *outside* Debian. Think about Enterprise (non-free) software like Oracle, HP Openview, Tivoli, Remedy... Do you expect vendors of this software to understand^Wimplement package management based dependencies for *all* Linux distributions? LSB tries to simplify the Linux environment for such software. Lsb_release is defined as the an answer to the question which distribution am I running in and which release is it? Developers of such software, taking the LSB as a reference, can use lsb_release to determine where they are in. However, if we lie [2] to these tools we are actually making this software break. Frankly, helping vendors of non-free software lies far below the ability to provide our users the option to do partial upgrades, apt-pinning, etc. If we are not going to impact the utility to the users; I am indifferent to adding things to help non-free software vendors. manoj -- It's easy to solve the halting problem with a shotgun. :-) Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ADV: Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, 01 Jun 2007 16:54:03 -0400, Kris Deugau [EMAIL PROTECTED] said: Frank Lichtenheld wrote: On Fri, Jun 01, 2007 at 02:51:27PM -0400, Kris Deugau wrote: (Mildly amusing sidenote to this discussion: I'm finally convincing the senior systems guy that Packages Are Good, and now developers for the upstream OS seem to be telling me Packages Are Useless, because I can't even count on a critical dependency being installed via the package system. g) ? I don't see that beeing said in the thread. Could you point out that for me? Hmm. Not explicitly stated, nor really implied, but several people commented that a system may have backported packages, packages from testing/unstable/experimental, software that's installed from source and which the package manager is therefore completely unaware of - in other words, no matter what you might find in /etc/debian_version or some other nominal reference, the configuration and binaries on the system may not resemble a stock install of that release at all. Taken to the extreme, that leads me to the conclusion that Packages Are Useless. g (Taken another couple of steps, it leads to Everyone should be running Linux From Scratch.) So, modular systems via packages that allow me to install a system according to my desires; in your world make packages useless? Upon my word, your logic seems wonderfully unique. manoj -- Pain is inevitable, suffering is optional. Author Unknown Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ADV: Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 01, 2007 at 04:54:03PM -0400, Kris Deugau wrote: Hmm. Not explicitly stated, nor really implied, but several people commented that a system may have backported packages, packages from testing/unstable/experimental, software that's installed from source and which the package manager is therefore completely unaware of - in other words, no matter what you might find in /etc/debian_version or some other nominal reference, the configuration and binaries on the system may not resemble a stock install of that release at all. That's right. Taken to the extreme, that leads me to the conclusion that Packages Are Useless. g (Taken another couple of steps, it leads to Everyone should be running Linux From Scratch.) You got it completely backwards. The individual packages (and their versions) are what you _can_ depend on. A single release string can never give you enough information for what you want to achieve. And this is not specific to Debian at all; you get the same effects on RPM-based distros when you start installing packages from 3rd party RPM repositories. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Wednesday 30 May 2007 22.46:30 Kris Deugau wrote: I've been writing custom utilities and libraries for various systems at work, and with one particular project recently it's become (more) important to know exactly which Debian release it's running on (at some stage or other between version-controlled-code and installed-binary) so that I don't try to call a missing binary or create a .deb that requires a package that doesn't actually exist in the target dist. In general: don't do that. My machine has base-files from etch and thus can be considered to be etch, but there are a lot of packages from lenny and sid on it (including libc6, thanks to the dependency handling). And if I don't reinstall the machine before lenny, it will even mix etch, lenny, lenny+1 and sid in a few years. So what version is installed on the machine? Version problems like you describe almost always boil down to versioned package dependencies. Obviously, if you're in a controlled environment and you know that your target machines are clean etch or lenny, the problem becomes a lot easier. cheers -- vbi -- featured product: GNU Privacy Guard - http://gnupg.org signature.asc Description: This is a digitally signed message part.
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Friday 01 June 2007 20.51:27 Kris Deugau wrote: Instead, we try to make them work as far as their dependencies are met. ... which means what, exactly, if my program expects /usr/lib/apache2/suexec but the system (stock Debian sarge) only has /usr/lib/apache2/suexec2? Or vice versa for etch? Just make sure you depend on whatever version of apache that matches where you expect the suexec binary to live. Yes, you'll need to check for all such cases but it will get you much further than relying on /etc/debian_version because even people heavily mixing Debian releases will be happy. cheers -- vbi -- 24h Business Support: ... for example, when one of our products stops working, we'll blame another vendor within 24 hours. -- Scott Adams/Dilbert, 2006-06-13 signature.asc Description: This is a digitally signed message part.
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Hi, I once wrote a small python utility called udist that tries to work out which distribution it runs on. It works on several RPM based distributions, as well as the Debian based distros I've tested. I originally had in mind putting the project on a public server and involving more people to test and implement more distros but I never got around to it. The utility makes use of different strategies when attempting to fill out the different fields. It can use LSB but can also carry on with out it as in the example below. This is the kind of output I get on my Ubuntu machine: [EMAIL PROTECTED] udist]$ bin/udist No LSB modules are available. id:ubuntu name:Ubuntu codename:feisty desc:Ubuntu 7.04 rel:7.04 rel_major:7 family:debian sfam:ubuntu reltag:ubuntu7 processor: machine:i686 arch:i386 ... and this is from a CentOS machine: [EMAIL PROTECTED] ~]$ udist id:centos name:CentOS codename:Final desc:CentOS release 4.4 (Final) rel:4.4 rel_major:4 family:redhat sfam:rhel reltag:el4 processor:athlon machine:i686 arch:i386 By using switches (a la uname) you can output specific fields. I've put a .tar.gz file here: ftp://ftp.bioxray.dk:/pub/mok/src/udist-0.5.tar.gz if you're interested. I anyone wants to join in and extend/rewrite/improve this utility, let me know. Cheers, Morten -- Morten Kjeldgaard, Asc. professor, Ph.D. Department of Molecular Biology, Aarhus University Gustav Wieds Vej 10 C, DK-8000 Aarhus C, Denmark Lab +45 89425026 * Mobile +45 51860147 * Fax +45 86123178 Home +45 86188180 * http://www.bioxray.dk/~mok -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
PS: To address the original question: Being a molecular biologist, my initial idea was to use an approach similar to that used in gene analysis: look at the entire set of packages installed on a specific system (package name and version), and then determine what known distro the set is closest related to. I put that aside because I wanted something working quickly, but the idea of being able to make a family tree of distros still seems like fun. It isn't hard to do. Cheers, Morten -- Morten Kjeldgaard, Asc. professor, Ph.D. Department of Molecular Biology, Aarhus University Gustav Wieds Vej 10 C, DK-8000 Aarhus C, Denmark Lab +45 89425026 * Mobile +45 51860147 * Fax +45 86123178 Home +45 86188180 * http://www.bioxray.dk/~mok -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 01, 2007 at 12:55:57AM +0200, Santiago Vila wrote:
I wonder why do we need a file to tell the user about the contents of
his /etc/apt/sources.list file. Have you read How do I know which
distribution I'm running? in base-files FAQ? The answer is still
valid for *any* file which is part of an installed package.
We are not telling the user, we are telling *programs* what environment they
are in. Reading /etc/apt/sources.list is useless. Let me give you some use
cases:
- a sysadmin running 'woody', upgraded to 'sarge' by changing his
/etc/apt/sources.list to point to 'stable'. But has not upgraded the system
after etch was released
/etc/debian_version - CORRECT info
/etc/apt/sources.list - INCORRECT info
- a sysadmin running 'sarge' modifies his /etc/apt/sources.list to point to
'etch', but never upgrades the system.
/etc/debian_version - CORRECT info
/etc/apt/sources.list - INCORRECT info
- a sysadmin installed 'etch' using d-i, and upgraded it after December 11th
but has not upgraded it before April 10th.
/etc/debian_version - INCORRECT info (4.0 when it is testing)
/etc/apt/sources.list - CORRECT info
- a sysadmin installs 'lenny' using d-i, April 9th. But never upgraded
before that.
/etc/debian_version - INCORRECT info (4.0 when it is testing)
/etc/apt/sources.list - CORRECT info ('testing')
Sources.list does not indicate the release the system is running but,
actually, the release the system would be running *if* it was up-to-date and
upgraded.
Moreso, it's completely useless for (some) systems that have been installed from
CD-ROM and do not point to the security mirrors.
It is useful *in*addition* to /etc/debian_version to make a guess and try to
tell apart testing vs. unstable.
I really don't understand what you guys want to achieve that might be both
necessary and really useful (as opposed to just being a nice thing).
We are trying to simplify the problem some applications might have (not
necessarily those shipped in Debian proper, maybe even for applications that
are for other vendors) in order to determine which system they are in and
take proper action. The problem that was originally stated at the start of
the thread.
The best approach we can provide ('use lsb_release') is prone to errors if
used in the timeframe of a release and, even for some other situations.
In any case, you said [1] there was some (programmatic) way to determine
which Debian release (or even 'non-release') an application is running one
which does not depend on /etc/debian_release. I would be happy to know which
one that is (so that it can be implemented in lsb_release).
Regards
Javier
[1] Message-ID: [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 01, 2007 at 02:26:34PM +0200, Morten Kjeldgaard wrote: PS: To address the original question: Being a molecular biologist, my initial idea was to use an approach similar to that used in gene analysis: look at the entire set of packages installed on a specific system (package name and version), and then determine what known distro the set is closest related to. You can check only a subset of packages (most popular ones, for example or core packages) and compare with data you extracted the data beforehand or somebody provides. For example, see the package data sets at http://distrowatch.com/debian (these can be easily generated with the Packages files from the different releases, but you have to have access to mirrors with old releases too) Regards Javier signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, 1 Jun 2007, Javier Fernández-Sanguino Peña wrote: On Fri, Jun 01, 2007 at 12:55:57AM +0200, Santiago Vila wrote: I wonder why do we need a file to tell the user about the contents of his /etc/apt/sources.list file. Have you read How do I know which distribution I'm running? in base-files FAQ? The answer is still valid for *any* file which is part of an installed package. We are not telling the user, we are telling *programs* what environment they are in. That's the fundamental mistake I see here: We should not be telling programs what release they are running to begin with. We do not try to make packages to work under the assumption that they will run on a sarge system or an etch system. Instead, we try to make them work as far as their dependencies are met.
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
(I keep looking at what I've written, and thinking That's not quite right or I'm forgetting some critical argument or That sounds very argumentative/rude but I can't think of a better way to phrase it. I *have* gotten an interesting discussion out of this thread, however.) Santiago Vila wrote: That's the fundamental mistake I see here: We should not be telling programs what release they are running to begin with. We do not try to make packages to work under the assumption that they will run on a sarge system or an etch system. Instead, we try to make them work as far as their dependencies are met. ... which means what, exactly, if my program expects /usr/lib/apache2/suexec but the system (stock Debian sarge) only has /usr/lib/apache2/suexec2? Or vice versa for etch? (Or more accurately, I need to know in advance - in this case, at package build time - which name suexec gets so that the Apache config fragment I drop in doesn't break.) OK, so if it's one file I can munge in a solution that checks at install time or something. What about a case where there are *hundreds* of little things like this with complicated subcases? This is the simplest, most prominent example I've run into, but it's far from the only one. Most of the rest are somewhat convoluted and specific to local systems (and a few are related to how I'm building packages to avoid Debian Policy limitations that conflict with local policy), but they're very real. I'm not trying to find something that includes (or resembles) significant fractions of the hairy mess that is an autotools configure script (g), but a reference I can use to make reasonable assumptions about what should be on the system if it hasn't been hacked fifteen different directions with source installs of half the major subsystems which rely on backports and packages from experimental. (Mildly amusing sidenote to this discussion: I'm finally convincing the senior systems guy that Packages Are Good, and now developers for the upstream OS seem to be telling me Packages Are Useless, because I can't even count on a critical dependency being installed via the package system. g) -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ADV: Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 01, 2007 at 02:51:27PM -0400, Kris Deugau wrote: (Mildly amusing sidenote to this discussion: I'm finally convincing the senior systems guy that Packages Are Good, and now developers for the upstream OS seem to be telling me Packages Are Useless, because I can't even count on a critical dependency being installed via the package system. g) ? I don't see that beeing said in the thread. Could you point out that for me? Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ADV: Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Frank Lichtenheld wrote: On Fri, Jun 01, 2007 at 02:51:27PM -0400, Kris Deugau wrote: (Mildly amusing sidenote to this discussion: I'm finally convincing the senior systems guy that Packages Are Good, and now developers for the upstream OS seem to be telling me Packages Are Useless, because I can't even count on a critical dependency being installed via the package system. g) ? I don't see that beeing said in the thread. Could you point out that for me? Hmm. Not explicitly stated, nor really implied, but several people commented that a system may have backported packages, packages from testing/unstable/experimental, software that's installed from source and which the package manager is therefore completely unaware of - in other words, no matter what you might find in /etc/debian_version or some other nominal reference, the configuration and binaries on the system may not resemble a stock install of that release at all. Taken to the extreme, that leads me to the conclusion that Packages Are Useless. g (Taken another couple of steps, it leads to Everyone should be running Linux From Scratch.) (I don't really think so, and I think the argument about The local admin may hack the system up until it resembles Swiss cheese so why bother doing x has been beaten well beyond death in other threads I've seen recently.) Mostly just an impression I got from the trend of some of the responses. -kgd, wondering how one would go about bootstrapping LFS raw from a stack of printout and a single modern desktop machine, with no source of precompiled executables. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, 01 Jun 2007 14:51:27 -0400, Kris Deugau [EMAIL PROTECTED] said: (I keep looking at what I've written, and thinking That's not quite right or I'm forgetting some critical argument or That sounds very argumentative/rude but I can't think of a better way to phrase it. I *have* gotten an interesting discussion out of this thread, however.) Santiago Vila wrote: That's the fundamental mistake I see here: We should not be telling programs what release they are running to begin with. We do not try to make packages to work under the assumption that they will run on a sarge system or an etch system. Instead, we try to make them work as far as their dependencies are met. ... which means what, exactly, if my program expects /usr/lib/apache2/suexec but the system (stock Debian sarge) only has /usr/lib/apache2/suexec2? Seems like you should use the new version, and add a versioned dependency? Or vice versa for etch? (Or more accurately, I need to know in advance - in this case, at package build time - which name suexec gets so that the Apache config fragment I drop in doesn't break.) OK, so if it's one file I can munge in a solution that checks at install time or something. What about a case where there are *hundreds* of little things like this with complicated subcases? Again, the dependency system is your friend. Use it. manoj -- Having the fewest wants, I am nearest to the gods. Socrates Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 01, 2007 at 04:54:03PM -0400, Kris Deugau wrote: Frank Lichtenheld wrote: On Fri, Jun 01, 2007 at 02:51:27PM -0400, Kris Deugau wrote: (Mildly amusing sidenote to this discussion: I'm finally convincing the senior systems guy that Packages Are Good, and now developers for the upstream OS seem to be telling me Packages Are Useless, because I can't even count on a critical dependency being installed via the package system. g) ? I don't see that beeing said in the thread. Could you point out that for me? Hmm. Not explicitly stated, nor really implied, but several people commented that a system may have backported packages, packages from testing/unstable/experimental, software that's installed from source and which the package manager is therefore completely unaware of - in other words, no matter what you might find in /etc/debian_version or some other nominal reference, the configuration and binaries on the system may not resemble a stock install of that release at all. But all of these problems except for the software not installed as a package at all are actually solvable inside the packages system. It is not solvable by polling a simple one-line file because the system is too complex for that, but the vastly larger /var/lib/dpkg/status has all the information you need. So your reason for stating (admittely half-joking, but still) that packages are useless is because they can't help you if you don't use them? That's too lame to be funny, IMHO... Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 01, 2007 at 02:51:27PM -0400, Kris Deugau wrote: Santiago Vila wrote: That's the fundamental mistake I see here: We should not be telling programs what release they are running to begin with. We do not try to make packages to work under the assumption that they will run on a sarge system or an etch system. Instead, we try to make them work as far as their dependencies are met. ... which means what, exactly, if my program expects /usr/lib/apache2/suexec but the system (stock Debian sarge) only has /usr/lib/apache2/suexec2? Or vice versa for etch? (Or more accurately, I need to know in advance - in this case, at package build time - which name suexec gets so that the Apache config fragment I drop in doesn't break.) And what do you do when the system says it's sarge, but the user trying to install your package is using a backport of apache2.2 because they needed some new feature, so suexec is under the new name? What do you do when the user installs the sarge version of your package, and then does a partial upgrade to etch? Heck, what do you do when the user installs the sarge version of your package, and does a *full* upgrade to etch? There's no channel by which your package is going to be notified of the changes to the versions of other installed packages. Package dependencies are the right answer here, not distribution-based guessing. OK, so if it's one file I can munge in a solution that checks at install time or something. What about a case where there are *hundreds* of little things like this with complicated subcases? Then you have a difficult task ahead of you to create a package that works for your users. But it's quite unrealistic that you will ever have a case of hundreds of little, *independent* things that differ between dists that you need to check for. Your hundred little changes are probably reducible to three or four versioned dependencies. (Mildly amusing sidenote to this discussion: I'm finally convincing the senior systems guy that Packages Are Good, and now developers for the upstream OS seem to be telling me Packages Are Useless, because I can't even count on a critical dependency being installed via the package system. g) You can depend on it if you're using dependencies right. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Wed, May 30, 2007 at 04:46:30PM -0400, Kris Deugau wrote: However, there doesn't seem to be any single, consistent, doesn't-change-for-the-life-of-the-release, programmatically possible (never mind *easy* just yet...) method to find out if I'm on Debian sarge, etch, lenny, or some third-party Debian-derived distribution. Your approach is wrong. Many machines have packages installed from multiple distributions simultaneously (sarge+etch, sarge+backports, etch+backports, etch+lenny, lenny+sid, sid+experimental are probably the most common combinations nowadays). Backported packages may even be compiled locally so they may not have any distribution associated with them at all. Some searching turned up a suggestion to use the glibc version as a reference... which might be OK if there weren't so much overlap between releases. :( (I checked woody, sarge, etch, and lenny. There was overlap between woody and *etch*, IIRC. Ewww.) Forget it. I already have a machine in production which is mostly etch but glibc and a handful of other packages are from lenny. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Thu, May 31, 2007 at 12:35:06AM +0200, Santiago Vila wrote:
Hi.
I believe there is something fundamentally wrong if you *have* to rely
on /etc/debian_version for anything. The number of Debian packages
actually using such file is probably zero (but I could be wrong).
Bastille uses it to distinguish releases. There seems to be others:
$ grep -l /etc/debian_version /*/bin/* 2/dev/null
/usr/bin/binstats
/usr/bin/bug-buddy
/usr/bin/euro-test
/usr/bin/gnome-bug
/usr/bin/gst-feedback-0.8
/usr/bin/imake
/usr/bin/lsb_release
/usr/bin/xine-bugreport
/usr/bin/xine-check
/usr/bin/xminicom
And this is NOT surprising for people who use linuxlogo:
$ find /var/lib/dpkg/info/ -type f -exec grep -l /etc/debian_version \{\} \;
[ .. snip base-files .. ]
/var/lib/dpkg/info/linuxlogo.preinst
/var/lib/dpkg/info/linuxlogo.postrm
Try using dependencies or run-time tests. Really.
Which runtime tests do you suggest? If there is a programatic way to
implement the test then lsb_release is the way to do it.
I actually think we should ship a *distinct* /etc/debian_version
in testing and not make it follow the sid-testing-stable dance. Otherwise
there is a timeframe in which sid's or testing's base-files say's it is
stable, when it's not.
Could there be a distinct package per distribution repository? One
(cumbersome?) way to do this is to have base-files maintainer (ehem, you)
upload new versions of the package to the proper distribituion. That way, the
contents of /etc/debian_version in the package in sid are never changed, and
the contents of the file in testing depend on its status:
a) during development /etc/debian_version reads 'CODENAME/testing'
b) during freeze /etc/debian_verion reads 'CODENAME/stable'
(this way, when testing is released, it will ship with that content,
right after the release a new package has to be uploaded to 'testing' to
go back to a)
The only issue with this is that you have to maintain always two branches
(sid and the next release) and whenever changes to other files in base-fles
are done you have to upload them to both releases.
However, this opens the possibility of introducing /etc/lsb-release in Debian
(not required by lsb, but nice to have for people who do not want to rely on
the lsb_release script) with properly structured content like:
DISTRIB_ID=Debian
DISTRIB_RELEASE=4.0
DISTRIB_CODENAME=etch
DISTRIB_DESCRIPTION=Debian GNU/Linux 4.0 'etch'
and
DISTRIB_ID=Debian
DISTRIB_RELEASE=testing
DISTRIB_CODENAME=lenny
DISTRIB_DESCRIPTION=Debian GNU/Linux testing 'lenny' (UNRELEASED)
Another (easier?, but strange) way to have this is to have base-files
depend: on a package like 'release-info' which only contained
/etc/debian_version and have different packages for each distribution which
are *not* transitioned from unstable-testing.
Similary to the solution above, its maintainer (the RMs?) would have to
upload a new package in *testing* just before a release (for example, during
the freeze) and upload a new package version to *testing* just after a
release. The contents of the package in sid would never change. However,
having a package just to handle a file looks like an overkill to me.
Either ways make the hacks introduced in lsb_release unnecesary.
Regards
Javier
signature.asc
Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Thursday 31 May 2007 12:11, Gabor Gombas wrote: Forget it. I already have a machine in production which is mostly etch but glibc and a handful of other packages are from lenny. That sounds a bit strange as the version of glibc in testing is the same as the one in stable. Or do you mean sid instead of lenny? pgp730y1PfRXN.pgp Description: PGP signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Thu, 31 May 2007, Javier Fernández-Sanguino Peña wrote:
On Thu, May 31, 2007 at 12:35:06AM +0200, Santiago Vila wrote:
Hi.
I believe there is something fundamentally wrong if you *have* to rely
on /etc/debian_version for anything. The number of Debian packages
actually using such file is probably zero (but I could be wrong).
Bastille uses it to distinguish releases. There seems to be others:
$ grep -l /etc/debian_version /*/bin/* 2/dev/null
/usr/bin/binstats
/usr/bin/bug-buddy
/usr/bin/euro-test
/usr/bin/gnome-bug
/usr/bin/gst-feedback-0.8
/usr/bin/imake
/usr/bin/lsb_release
/usr/bin/xine-bugreport
/usr/bin/xine-check
/usr/bin/xminicom
Using them (to show its contents, for example) is one thing, relying
on them to achieve different behaviour is another one. The former
might be acceptable, the latter should not be.
And this is NOT surprising for people who use linuxlogo:
$ find /var/lib/dpkg/info/ -type f -exec grep -l /etc/debian_version \{\} \;
[ .. snip base-files .. ]
/var/lib/dpkg/info/linuxlogo.preinst
/var/lib/dpkg/info/linuxlogo.postrm
Try using dependencies or run-time tests. Really.
Which runtime tests do you suggest? [...]
Consider the example given by Kris: If you need to know how apache
does such and such, you should rely on the actual apache version you
have installed, not on base-files, because the user might have a mix
of packages from sarge and etch.
I actually think we should ship a *distinct* /etc/debian_version
in testing and not make it follow the sid-testing-stable dance. Otherwise
there is a timeframe in which sid's or testing's base-files say's it is
stable, when it's not.
That would bless the abuse of /etc/debian_version. IMHO, it would be
good for Debian if we continue to discourage its use.
A lot of time ago, there was a paragraph somewhere (policy? packaging manual?)
saying something like Debian packages are not tied to a given release
and the dependency system has allowed us so far to keep the spirit of that.
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Thu, 31 May 2007, Javier Fernández-Sanguino Peña wrote: On Thu, May 31, 2007 at 02:06:28PM +0200, Santiago Vila wrote: That would bless the abuse of /etc/debian_version. IMHO, it would be good for Debian if we continue to discourage its use. LSB compliance (which is a release goal) obliges us to provide proper versioning information for releases. That means we have to have a (standard) way for other software to determine which version of our distribution they are running in. The lsb_release scripts relies on /etc/debian_version. It also uses of /etc/apt/sources.list is a -bad- hack to work around the testing/unstable problem (and introduces some bugs). As you are the maintainer for base-files, and it provides /etc/debian_version, what do you suggest we do for LSB compliance? I suggest we forget about LSB compliance of testing and unstable, since they are not really releases.
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
The Fungi wrote: On Wed, May 30, 2007 at 04:46:30PM -0400, Kris Deugau wrote: [...] On RHEL and derived distros, there's usually a file /etc/redhat-release (sometimes renamed, but usually trivially enough that it can be found with little trouble) containing both the distro code name and the version number. [...] Not to be patronizing, Don't worry about that. g but you are aware of the /etc/debian_version file, yes? No. g But now I am. It's looking more promising that any other approach, too. -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Thu, May 31, 2007 at 02:06:28PM +0200, Santiago Vila wrote: That would bless the abuse of /etc/debian_version. IMHO, it would be good for Debian if we continue to discourage its use. LSB compliance (which is a release goal) obliges us to provide proper versioning information for releases. That means we have to have a (standard) way for other software to determine which version of our distribution they are running in. The lsb_release scripts relies on /etc/debian_version. It also uses of /etc/apt/sources.list is a -bad- hack to work around the testing/unstable problem (and introduces some bugs). As you are the maintainer for base-files, and it provides /etc/debian_version, what do you suggest we do for LSB compliance? Quite frankly, if you are actively opposing its use I would like to suggest release managers to get involved and help fix this ambiguous situation for the next release. Friendly, Javier signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian?release a program is running on?
On Thu, May 31, 2007 at 01:50:50PM +0200, Frans Pop wrote: That sounds a bit strange as the version of glibc in testing is the same as the one in stable. Or do you mean sid instead of lenny? Oops, you're right. It's etch+sid. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
* Javier Fernández-Sanguino Peña [Thu, 31 May 2007 12:33:07 +0200]: Hello. I actually think we should ship a *distinct* /etc/debian_version in testing and not make it follow the sid-testing-stable dance. Otherwise there is a timeframe in which sid's or testing's base-files say's it is stable, when it's not. Like Javier, I also think that it'd be desirable to have somewhere, be it /etc/debian_version or not, distinct information about the release. His idea about /etc/lsb-release sounds sensible to me: However, this opens the possibility of introducing /etc/lsb-release in Debian (not required by lsb, but nice to have for people who do not want to rely on the lsb_release script) with properly structured content like: DISTRIB_ID=Debian DISTRIB_RELEASE=4.0 DISTRIB_CODENAME=etch DISTRIB_DESCRIPTION=Debian GNU/Linux 4.0 'etch' and DISTRIB_ID=Debian DISTRIB_RELEASE=testing DISTRIB_CODENAME=lenny DISTRIB_DESCRIPTION=Debian GNU/Linux testing 'lenny' (UNRELEASED) Santiago, would you be willing to introduce this new file (distinct from /etc/debian_version) into base-files, and maintain two separate branches of the package as explained by Javier? If not, Javier's idea about introducing a new packagae for this file seems the only option left, and I wouldn't mind maintaining it. Other packages like lsb-release and maybe base-files could depend on it. Though I think it'd be best to ship /etc/lsb-release on base-files itself. Either ways make the hacks introduced in lsb_release unnecesary. This sounds desirable, yes. Let's wait for Santiago's opinion. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org It is impossible to make anything foolproof because fools are so ingenious. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, 1 Jun 2007, Adeodato Simó wrote: Santiago, would you be willing to introduce this new file (distinct from /etc/debian_version) into base-files, and maintain two separate branches of the package as explained by Javier? That would be an ugly hack. base-files is a package which is uploaded for unstable and then propagates to testing, like any other package, so it's definitely not the place for something that should be different in testing and unstable. I wonder why do we need a file to tell the user about the contents of his /etc/apt/sources.list file. Have you read How do I know which distribution I'm running? in base-files FAQ? The answer is still valid for *any* file which is part of an installed package. I really don't understand what you guys want to achieve that might be both necessary and really useful (as opposed to just being a nice thing).
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Gabor Gombas [EMAIL PROTECTED] writes: On Wed, May 30, 2007 at 04:46:30PM -0400, Kris Deugau wrote: However, there doesn't seem to be any single, consistent, doesn't-change-for-the-life-of-the-release, programmatically possible (never mind *easy* just yet...) method to find out if I'm on Debian sarge, etch, lenny, or some third-party Debian-derived distribution. Your approach is wrong. Many machines have packages installed from multiple distributions simultaneously (sarge+etch, sarge+backports, etch+backports, etch+lenny, lenny+sid, sid+experimental are probably the most common combinations nowadays). Backported packages may even be compiled locally so they may not have any distribution associated with them at all. Hm, it's often not a good idea to tell people that they're doing something wrong just because it doesn't work globally with everyone's systems. It can come across poorly, and often what they're asking for makes perfect sense in their environment. If we as a project can't provide them with the right tool because it doesn't make sense in our context, that's a good response, but just telling them they're taking the wrong approach isn't particularly useful. For example, at Stanford, while some of our staff workstations do have those package mixes, our servers are either sarge or etch. Asking whether a given server is sarge or etch is a quite reasonable and rational question with a well-defined response. And it is very useful for us to be able to select, inside Puppet, whether a given system is sarge or etch (to take an obvious example, we want to maintain sources.list via Puppet, but we don't want Puppet to convert a sarge system to an etch system or vice versa). Doing that via automatic discovery on the system is the right approach since maintaining a list of what systems are which (ever-changing given that we're doing upgrades now) would be tedious and often inaccurate for our hundreds of servers. lsb-release via facter works quite well for this purpose for us. That it doesn't work with sid/lenny systems isn't a problem for us currently, and will never be a problem provided that it's fixed before lenny becomes stable. :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Is there a way to positively, uniquely identify which Debian release a program is running on?
I've been writing custom utilities and libraries for various systems at work, and with one particular project recently it's become (more) important to know exactly which Debian release it's running on (at some stage or other between version-controlled-code and installed-binary) so that I don't try to call a missing binary or create a .deb that requires a package that doesn't actually exist in the target dist. (Apache's suexec is one particular example; it's /usr/lib/apache2/suexec2 on sarge, but /usr/lib/apache2/suexec on etch. I could solve that particular case with some hackery in one of several possible places, but it's a little harder for things like package dependencies that have to change a little between different releases or distros.) However, there doesn't seem to be any single, consistent, doesn't-change-for-the-life-of-the-release, programmatically possible (never mind *easy* just yet...) method to find out if I'm on Debian sarge, etch, lenny, or some third-party Debian-derived distribution. Nor does there seem to be any similar indicator to see if I'm on Debian 3.0, 3.1, 4.0, or whatever version list a third-party distro is up to this week. (Side note: When is the number version of a new release decided?) On RHEL and derived distros, there's usually a file /etc/redhat-release (sometimes renamed, but usually trivially enough that it can be found with little trouble) containing both the distro code name and the version number. It may change a little on point releases, but it's stable, consistent, and unique to each release. Some searching turned up a suggestion to use the glibc version as a reference... which might be OK if there weren't so much overlap between releases. :( (I checked woody, sarge, etch, and lenny. There was overlap between woody and *etch*, IIRC. Ewww.) -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
This one time, at band camp, Kris Deugau said: On RHEL and derived distros, there's usually a file /etc/redhat-release (sometimes renamed, but usually trivially enough that it can be found with little trouble) containing both the distro code name and the version number. The closest we ship is /etc/debian_version. I use it for several similar tests at work, you just need to keep a mental map between the number and the version string. If you can count lsb-release being installed, that will give you more information, or you could just look at the tests it performs to get an idea of how it distinguishes releases. Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Hi, * Kris Deugau [EMAIL PROTECTED] [2007-05-30 23:06]: [...] However, there doesn't seem to be any single, consistent, doesn't-change-for-the-life-of-the-release, programmatically possible (never mind *easy* just yet...) method to find out if I'm on Debian sarge, etch, lenny, or some third-party Debian-derived distribution. Nor does there seem to be any similar indicator to see if I'm on Debian 3.0, 3.1, 4.0, or whatever version list a third-party distro is up to this week. (Side note: When is the number version of a new release decided?) On RHEL and derived distros, there's usually a file /etc/redhat-release (sometimes renamed, but usually trivially enough that it can be found with little trouble) containing both the distro code name and the version number. It may change a little on point releases, but it's stable, consistent, and unique to each release. /etc/debian_version Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpzgl56Gthuy.pgp Description: PGP signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Hi. I believe there is something fundamentally wrong if you *have* to rely on /etc/debian_version for anything. The number of Debian packages actually using such file is probably zero (but I could be wrong). Try using dependencies or run-time tests. Really. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Wed, May 30, 2007 at 04:46:30PM -0400, Kris Deugau wrote: However, there doesn't seem to be any single, consistent, /etc/debian_version ? Don't know when it was introduced though... -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Wed, May 30, 2007 at 04:46:30PM -0400, Kris Deugau wrote:
[...]
On RHEL and derived distros, there's usually a file /etc/redhat-release
(sometimes renamed, but usually trivially enough that it can be found
with little trouble) containing both the distro code name and the
version number.
[...]
Not to be patronizing, but you are aware of the /etc/debian_version
file, yes?
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Wed, May 30, 2007 at 10:12:38PM +0100, Stephen Gran wrote: The closest we ship is /etc/debian_version. I use it for several similar tests at work, you just need to keep a mental map between the number and the version string. If you can count lsb-release being installed, that will give you more information, or you could just look at the tests it performs to get an idea of how it distinguishes releases. Only problem with /etc/debian_version is that you cannot distinguish testing from sid and there's a timeframe (when base-files is updated, in which you will confuse a 'sid' system with the next release). You can run 'lsb_release -a' a better estimate. Actually, it should be able to cope derived distributions that have adapted /etc/lsb-release. The script is provided by package lsb-release, but it's extra priority, so not bound to be installed in most systems. The script originally did not cope with the testing/unstable issue, see #341231. Right now it should cope with most common cases but there might be some weird situations in which it does not provide the correct answer. For example: if a system's /etc/apt/sources.list is not properly configured, if the system was installed ages ago with the 'testing' version of the installer for the a current release (and has never been updated) or because of weird setups (see #417145) It also hardcodes the codename for testing, that's why bugs like #425646 popup just after a release. I wonder if we should be shipping an /etc/lsb-release file? It was removed from the lsb package (in 3.0-6, september 2005) but did not move over to base-files... Regards Javier signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Wed, 2007-05-30 at 22:12 +0100, Stephen Gran wrote:
This one time, at band camp, Kris Deugau said:
On RHEL and derived distros, there's usually a file /etc/redhat-release
(sometimes renamed, but usually trivially enough that it can be found
with little trouble) containing both the distro code name and the
version number.
The closest we ship is /etc/debian_version. I use it for several
similar tests at work, you just need to keep a mental map between the
number and the version string. If you can count lsb-release being
installed, that will give you more information, or you could just look
at the tests it performs to get an idea of how it distinguishes
releases.
The command name is lsb_release. Its implementation is
distribution-specific. Debian's reads APT policy and then
debian_version:
def guess_debian_release():
distinfo = {'ID' : 'Debian'}
kern = os.uname()[0]
if kern in ('Linux', 'Hurd', 'NetBSD'):
distinfo['OS'] = 'GNU/'+kern
elif kern == 'FreeBSD':
distinfo['OS'] = 'GNU/k'+kern
else:
distinfo['OS'] = 'GNU'
distinfo['DESCRIPTION'] = '%(ID)s %(OS)s' % distinfo
rinfo = guess_release_from_apt()
if rinfo:
release = rinfo.get('version')
if release:
codename = lookup_codename(release, 'n/a')
else:
release = rinfo.get('suite', 'unstable')
if release == 'testing':
# Would be nice if I didn't have to hardcode this.
codename = TESTING_CODENAME
else:
codename = 'sid'
distinfo.update({ 'RELEASE' : release, 'CODENAME' : codename })
elif os.path.exists('/etc/debian_version'):
release = open('/etc/debian_version').read().strip()
if not release[0:1].isalpha():
# /etc/debian_version should be numeric
codename = lookup_codename(release, 'n/a')
distinfo.update({ 'RELEASE' : release, 'CODENAME' : codename })
else:
distinfo['RELEASE'] = release
if 'RELEASE' in distinfo:
distinfo['DESCRIPTION'] += ' %(RELEASE)s' % distinfo
if 'CODENAME' in distinfo:
distinfo['DESCRIPTION'] += ' (%(CODENAME)s)' % distinfo
return distinfo
lsb-release has Priority: extra so it's not that likely to be installed.
I've still doing distribution recognition by grepping
/etc/*-release /etc/release /etc/debian_version.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
signature.asc
Description: This is a digitally signed message part
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Ben Hutchings [EMAIL PROTECTED] writes: lsb-release has Priority: extra so it's not that likely to be installed. I've still doing distribution recognition by grepping /etc/*-release /etc/release /etc/debian_version. lsb-release is quite nice when using facter (usually via Puppet), since it uses lsb-release to fill out information that's handy to use in Puppet rules. Unfortunately, currently lsb-release Recommends: lsb, which then installs the entire world (like apparently large chunks of Qt) if one uses the default behavior of aptitude. (Bug filed.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
