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
[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
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
[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
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
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
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
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
[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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
(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:
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
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
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
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
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
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
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
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
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
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)
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
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.
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
--
* 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
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
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
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
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
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
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
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
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.
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
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
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
54 matches
Mail list logo
