Because not all Linux distributions follow Linux Standard Base. It would be silly for (to use an example) Arch to have a lsb-release file when it's very method is anything but LSB. So os-release gives a unified file regardless of the distro methodology. In fact this file could easily be extended beyond Linux to any Unix-like OS - which lsb-release would be less practical for.
>To address this, the standard does not dictate what package format the software system must use for its own packages, merely that RPM must be supported to allow packages from third-party distributors to be installed on a conforming system.
Well yeah, that's how Debian gets around the issue. However Arch doesn't have an RPM converter in it's standard set up (or if there is, I'm unaware of it).
Personally I massively prefer Arch's package manager to anything I've seen on any RPM-based distro and it seems pretty pointless in having an "alien"-like RPM converter for Arch given how exhaustive Pacman + AUR is. However the point remains that Arch would fail LSB due to this.
Well you said that Arch would fail LSB because it didn't have a converter, which seems strange if - as my link appears to show - it is capable of using RPM natively. That is why do they need to convert .rpm packages if they can run RPM and install them direct? Not that I'm saying there wouldn't be any work to do but the fact that people are already using .rpm via RPM (the binary program) would appear to show it's not a huge obstacle.
To me says that the distro can use any package format it likes ("The implementation itself may use a different packaging format for its own packages") as long as it can handle .rpm packages ("Implementations shall provide a mechanism for installing applications in this [RPM] packaging format"). So if Arch shipped RPM it would appear [superficially] to meet the requirements.
Comments
Because not all Linux distributions follow Linux Standard Base. It would be silly for (to use an example) Arch to have a lsb-release file when it's very method is anything but LSB. So os-release gives a unified file regardless of the distro methodology. In fact this file could easily be extended beyond Linux to any Unix-like OS - which lsb-release would be less practical for.
Wait, I didn't know that and I use Arch - what's with Arch and LSB?
Well for one thing LSB mandates using RPMs: http://en.wikipedia.org/wiki/Linux_Standard_Base#Choice_of_R...
>To address this, the standard does not dictate what package format the software system must use for its own packages, merely that RPM must be supported to allow packages from third-party distributors to be installed on a conforming system.
I don't see a problem.
Well yeah, that's how Debian gets around the issue. However Arch doesn't have an RPM converter in it's standard set up (or if there is, I'm unaware of it).
Personally I massively prefer Arch's package manager to anything I've seen on any RPM-based distro and it seems pretty pointless in having an "alien"-like RPM converter for Arch given how exhaustive Pacman + AUR is. However the point remains that Arch would fail LSB due to this.
>Arch doesn't have an RPM converter
Doesn't it need to just run rpm binary itself - http://aur.archlinux.org/packages.php?ID=16857 kinda suggests that's more than feasible.
But again, that's in not in the official repositories (just AUR), let alone part of the base system.
It's great that it's available in AUR, but it wouldn't be enough to pass LSB - which is the /entire/ point of this tangent.
Well you said that Arch would fail LSB because it didn't have a converter, which seems strange if - as my link appears to show - it is capable of using RPM natively. That is why do they need to convert .rpm packages if they can run RPM and install them direct? Not that I'm saying there wouldn't be any work to do but the fact that people are already using .rpm via RPM (the binary program) would appear to show it's not a huge obstacle.
http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB...
To me says that the distro can use any package format it likes ("The implementation itself may use a different packaging format for its own packages") as long as it can handle .rpm packages ("Implementations shall provide a mechanism for installing applications in this [RPM] packaging format"). So if Arch shipped RPM it would appear [superficially] to meet the requirements.