Bug#914287: marked as done (lsb-release: please parse /usr/lib/os-release and deprecate /etc/lsb-release)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Bug#914287: marked as done (lsb-release: please parse /usr/lib/os-release and deprecate /etc/lsb-release)

Debian Bug Tracking System
Your message dated Wed, 28 Nov 2018 19:49:38 +0000
with message-id <[hidden email]>
and subject line Bug#914287: fixed in lsb 10.2018112800
has caused the Debian Bug report #914287,
regarding lsb-release: please parse /usr/lib/os-release and deprecate /etc/lsb-release
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [hidden email]

914287: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914287
Debian Bug Tracking System
Contact [hidden email] with problems

Package: lsb-release
Version: 9.20170808
Severity: wishlist

Debian's Python implementation of the LSB-standardized lsb_release
command parses various sources of data, including the non-standardized
configuration file /etc/lsb-release. That file doesn't exist in Debian,
but is typically shipped in base-files by derivatives. It is not "API"
itself, although packages designed for Ubuntu sometimes treat it as
though it was.

systemd defines a new "API", which has been adopted in Debian even
for non-systemd systems: the /usr/lib/os-release file (formerly
/etc/os-release, which is now a symlink). This "API" is defined in terms
of parsing a text file, not running a Python program, so it's much faster
to use.

If lsb_release looked at /usr/lib/os-release, then derivatives could edit
that file and /etc/dpkg/origins/default (which they need to do anyway)
and wouldn't usually need to add /etc/lsb-release. /usr/lib/os-release
uses the same subset of shell syntax as /etc/lsb-release.

The fields are:

lsb_release -r, --release: e.g. "9.6"
    /etc/lsb-release DISTRIB_RELEASE

    This appears to be os-release's optional VERSION_ID (not VERSION,
    for which the example given in the man page includes a Fedora release
    codename as well as the bare version number), except that stretch's
    os-release just says "9", not "9.6". For the sorts of uses people
    make of lsb_release (for example gating features that should only be
    enabled in newer Debian), I think it would probably make most sense
    for this to be 10 for the whole lifetime of buster, ignoring point
    releases?  Or it could preferentially come from /etc/debian_version,
    which would retain the minor version.

lsb_release -c, --codename: e.g. "stretch"
    /etc/lsb-release DISTRIB_CODENAME

    This is exactly os-release's optional VERSION_CODENAME.

lsb_release -i, --id: e.g. "Debian" or "Ubuntu"
    /etc/lsb-release DISTRIB_ID
    /etc/dpkg/origins/default Vendor

    There is no direct equivalent in os-release (ID is "debian", NAME is
    "Debian GNU/Linux", neither of which matches) but /etc/dpkg/origins
    should be sufficient to not need /etc/lsb-release; using os-release
    ID, possibly transformed to title-case, might be a good fallback.

lsb_release -d, --description: e.g. "Debian GNU/Linux 9.6 (stretch)"
    /etc/lsb-release DISTRIB_DESCRIPTION
    Fallback is "${ID} ${OS} ${RELEASE} (${CODENAME})"

    os-release PRETTY_NAME looks suitable for this. It can include the
    OS vendor, version number and/or codename. One difference is that
    stretch has PRETTY_NAME="Debian GNU/Linux 9 (stretch)", without the
    9.6; but I don't think that's a very important distinction, so it
    might make most sense for $(lsb_release -ds) in the buster release
    to be "Debian GNU/Linux 10 (buster)" across all point releases.


Source: lsb
Source-Version: 10.2018112800

We believe that the bug you reported is fixed in the latest version of
lsb, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [hidden email],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
Didier Raboud <[hidden email]> (supplier of updated lsb package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [hidden email])

Hash: SHA512

Format: 1.8
Date: Wed, 28 Nov 2018 20:21:37 +0100
Source: lsb
Binary: lsb-base lsb-release
Architecture: source
Version: 10.2018112800
Distribution: unstable
Urgency: medium
Maintainer: Debian LSB Team <[hidden email]>
Changed-By: Didier Raboud <[hidden email]>
 lsb-base   - Linux Standard Base init script functionality
 lsb-release - Linux Standard Base version reporting utility
Closes: 914287
 lsb (10.2018112800) unstable; urgency=medium
   * Remove support for /etc/lsb-release in favour of /usr/lib/os-release
     (Closes: #914287)
   * Rephrase lsb-release's README.Debian
   * Packaging cleanup
     - Bump S-V without changes needed
     - Bump debhelper compat to 11
     - Move Vcs to Salsa, update Vcs-*
     - Drop obsolete X-Python3-Version from d/control
     - d/copyright: use https URL
 d73858bd372cee6f4af083920d4fb52f4cddfb7e 1695 lsb_10.2018112800.dsc
 d895b56c9f6da02e8897b84906f3e327bc3e7fa7 42076 lsb_10.2018112800.tar.xz
 8b280e3fbf938eead60d64c92d23425968b44edd91fcbed8c9206c25229616c9 1695 lsb_10.2018112800.dsc
 5a3469feef00979bdc00f85607c35df9f45ff312a44c91179400d63300184c08 42076 lsb_10.2018112800.tar.xz
 b7845c87ead3fcfa6af6ba6407f98a3e 1695 misc extra lsb_10.2018112800.dsc
 5de465109944d4b347e9a07fbe4247a9 42076 misc extra lsb_10.2018112800.tar.xz