#133 Issue closed: Unwanted dependency on lsb package in package spec file¶
Labels: discuss / RFC
jezzaaa opened issue at 2012-07-26 02:50:¶
I have servers on which I don't want to install the LSB package because of all of the dependencies it brings in. I would like to be able to install a rear package and just create an os.conf file. Instead of making lsb a mandatory dependency, perhaps the post-install script can create the os.conf file automatically (or os.conf.nolsb) if lsb is not installed, or at least tell the user to do one or the other. The spec file should be able to work out the correct distro and release without any trouble.
dagwieers commented at 2012-07-26 15:05:¶
This is in fact already the case through OBS. The packages do not depend on the LSB packages, and an os.conf is created by the SPEC file bas on the distribution.
If this is not exactly as you want it, please reopen and provide more details.
jezzaaa commented at 2012-07-27 01:44:¶
This sounds exactly how I want it.
But IMHO I should be able to get this result building my own package using the spec file provided in the source code. The one I'm using, for SUSE, has "Requires: iproute2 lsb". I see that it is conditional on %{?suse_version} being non-zero. So I don't know how the OBS gets around this, unless they're using a different spec file. I'm using SLES v10p3.
Similarly, is there a reason that portmap/rpcbind is "Requires"d? I don't use NFS. Or is this also not required in the OBS package?
Apparently I don't have permission to reopen this issue.
schlomo commented at 2012-07-27 09:02:¶
Hi,
I am against writing long if-clauses to guess the OS and OS version.
That
was the main reason for the dependency on the lsb package (as it gives
us a
standard API-style way to know the OS and version). Besides that lsb
requires a certain set of standard tools which we then don't need to
require individually.
If you can suggest a replacement for discovering the OS (one that we
don't
have to maintain for new OSes and versions), then please go ahead and
submit a patch.
BTW, I would see one serious risk if one would set the OS version in a
%post script: Imagine someone updates the OS without updating the ReaR
package. Then ReaR would work with the old OS version and not know
about
the update. Thus any special fix which ReaR has for either the old or
the
new OS version would not work properly.
Regards,
Schlomo
dagwieers commented at 2012-08-12 22:31:¶
@jezzaaa You should be able to reopen. Not sure why you couldn't though ? So I reopened for you ;-)
@schlomo Your concern is correct, but applies only to certain distributions and/or cases. My preferences is to depend on lsb in those cases where requiring lsb is practically possible (e.g. not pulling Xorg, cups and other non-sense dependencies by default). So maybe we should reconsider our practice to also accommodate newer distributions (e.g. RHEL6) where the lsb dependency chain is more practical. However this requires a better understanding of each distribution/version...
gdha commented at 2012-12-19 08:50:¶
I have seen funny behavior of rear with a wrongos.conf file (due to
installing wrong distro-rpm), so in MHO the lsb package is still the
safest to determine the current OS.
BTW are there alternatives for lsb? If some has an idea please come
forward and tell us about it...
schlomo commented at 2012-12-19 09:07:¶
Hi,
originally I added the dependency to the lsb_release tool to spare us
the
hassle of OS detection. lsb_release has a clear and stable interface
and is
AFAIK supported on all Linux distros.
Unfortunately many Linux distros pull in a lot of extra packages to
install
lsb_release because they don't separate the different lsb features
into
subpackages. Even those who do tend to do it wrong:
[sschapiro@devgss02 ~]$ lsb_release -a
LSB Version:
:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: Scientific
Description: Scientific Linux release 6.3 (Carbon)
Release: 6.3
Codename: Carbon
[sschapiro@devgss02 ~]$ rpm -qf
/etc/lsb-release.d/printing-4.0-noarch
redhat-lsb-printing-4.0-3.el6.x86_64
redhat-lsb-4.0-3.el6.x86_64
[sschapiro@devgss02 ~]$ rpm -q --whatrequires redhat-lsb-printing
redhat-lsb-4.0-3.el6.x86_64
So installing redhat-lsb (which provides lsb_release) pulls in the
printing
stuff which pulls in cups, ppds, gs and so on. Debian is a little
better
because it spread the lsb functions over more packages:
sschapiro@isdeblnnl002:~$ apt-cache search lsb-
lsb - Linux Standard Base 4.0 support package
lsb-base - Linux Standard Base 4.0 init script functionality
lsb-core - Linux Standard Base 4.0 core support package
lsb-cxx - Linux Standard Base 4.0 C++ support package
lsb-desktop - Linux Standard Base 4.0 Desktop support package
lsb-graphics - Linux Standard Base 4.0 graphics support package
lsb-printing - Linux Standard Base 4.0 Printing package
lsb-release - Linux Standard Base version reporting utility
liblinux-distribution-perl - detect on which Linux distribution we are
running
lsb-appchk3 - LSB v3.x Application checking tool
lsb-build-base3 - LSB v3.x Development tools base package
lsb-build-cc3 - LSB v3.x Development environment lsbcc package
lsb-build-desktop3 - LSB v3.x Development tools desktop package
lsb-invalid-mta - Linux Standard Base sendmail dummy
lsb-languages - Linux Standard Base 4.0 Runtime Languages package
lsb-multimedia - Linux Standard Base 4.0 Multimedia package
lsb-pkgchk3 - LSB v3.x package checking tool
lsb-qt4 - Linux Standard Base 4.0 Qt4 support package
lsb-security - Linux Standard Base 4.0 Security package
Long way to go till we get the distros to get better, supporters are
most
welcome.
Regards,
Schlomo
PS: The above RHEL6 strangeness about 2 packages owning the same file is
a
"feature" of RPM that allows that if-and-only-if the file is identical
in
both packages. IMHO it is a RHEL6 bug that redhat-lsb-printing is
installed
by default and that redhat-lsb requires it.
jezzaaa commented at 2012-12-19 22:43:¶
I'm not sure where that leaves me. Perhaps I just install the lsb package with "--nodeps". :-(
schlomo commented at 2012-12-20 09:38:¶
You can sure do that, but the next yum upgrade will fix it for you :-)
Are
you a paying RH customer? Then you should open that as a bug. I will do
the
same at work.
jhoekx commented at 2012-12-21 10:36:¶
From the RHEL 6.4 release notes:
New redhat-lsb-core Package
When installing the redhat-lsb package, a large number of dependencies is pulled into the system to meet the LSB standard. Red Hat Enterprise Linux 6.4 provides a new redhat-lsb-core subpackage which allows you to easily fetch only the minimal set of required packages by installing the redhat-lsb-core package.
I hope that will help.
schlomo commented at 2012-12-21 13:14:¶
Great! Thanks for the info.
gdha commented at 2013-10-14 14:49:¶
@jezzaaa @jhoekx @schlomo @dagwieers May we close this issue? Nothing has been added for a very long time, and not sure what we can add?
schlomo commented at 2013-10-14 15:21:¶
well, as long as nobody adjusts the SPEC file to require only the
redhat-lsb-core package if RHEL >= 6.4 is found, then nothing will
change.
On 14 October 2013 16:49, gdha notifications@github.com wrote:
@jezzaaa https://github.com/jezzaaa @jhoekx https://github.com/jhoekx
@schlomo https://github.com/schlomo @dagwieershttps://github.com/dagwieersMay we close this issue? Nothing has been added for a very long time, and
not sure what we can add?—
Reply to this email directly or view it on GitHubhttps://github.com/rear/rear/issues/133#issuecomment-26260370
.
jezzaaa commented at 2013-10-14 15:34:¶
I'm not entirely happy. I can't see the lsb dependency being removed from the SPEC, nor can I see a fall-back to a cascade of if/then/else being accepted either. I don't know what else to suggest, and nobody else has come forward in 10 months with any new ideas. So while I still think this is a bug in ReAR, there's no point in keeping the ticket open, only to get closed in 12 months. So if there's no more discussion right now, you might as well close the ticket.
schlomo commented at 2013-10-14 21:27:¶
Sorry for your disappointment. ReaR unfortunately cannot fix all OS
vendor
bugs...
On Monday, October 14, 2013, jezzaaa wrote:
I'm not entirely happy. I can't see the lsb dependency being removed from
the SPEC, nor can I see a fall-back to a cascade of if/then/else being
accepted either. I don't know what else to suggest, and nobody else has
come forward in 10 months with any new ideas. So while I still think this
is a bug in ReAR, there's no point in keeping the ticket open, only to get
closed in 12 months. So if there's no more discussion right now, you might
as well close the ticket.—
Reply to this email directly or view it on GitHubhttps://github.com/rear/rear/issues/133#issuecomment-26264134
.
[Export of Github issue for rear/rear.]