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 t
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/st
[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 ma
[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 s
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 wou
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
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_r
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-
[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 fr
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^
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 the
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 rea
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 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 distribu
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 sug
> 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 ve
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 manag
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
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
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 ve
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 versi
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 ma
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 d
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 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 f
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
> *hav
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, bec
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
(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 wro
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?"
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 n
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 whic
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
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
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 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 uplo
* 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 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
--
-
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.
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 an
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 g
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 us
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 "si
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
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
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 i
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
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
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 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,bon
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 P
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 th
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
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 tr
54 matches
Mail list logo
