[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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. 



[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).

Attachment: signature.asc
Description: Digital signature

Reply to: