© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
Hello Amarnath,
many thanks for your explanation!
I found out what went wrong here during the build.
Basically it is one more instance of the "RPM and directories" annoyance.
If "make install" creates an empty directory, RPM does not care.
I added "touch %{buildroot}
and - voila - I got:
=======
RPM build errors:
Installed (but unpackaged) file(s) found:
/var/lib/hp/foo
=======
This "RPM and directories" behaviour make it hard to provide
complete RPMs because usually I rely on that RPM detects
changes in what is installed by "make install".
FYI, regarding "RPM and directories annoyance" you may have a look at
http://
Regarding "3 hplip rpm packages" at openSUSE:
If it was only me who makes the decisions I would usually provide
software that comes as one piece in one tar ball from upstream
also in one piece of binary package because it would be much more simple
for me and for most (but not all) of our users.
But there are some users and decision makers who believe in
splitting software is THE right thing (TM). Their reasoning is that
this way users can install only those exact parts of the whole
software that the particular user actually needs.
To a certain extent I even agree in particular when the question is
if a software is used on a server system or on a desktop system.
From my point of view the main difference here is that on a
server system there is usually neither X11 nor graphical GUI software
like Gtk or QT installed and the server admins do not want to have
such software installed because they want to keep their server systems
small because they do not want to care about maintenance (in particular
security updates) for software which is not really needed on their servers.
Therefore I agree that the core parts of HPLIP so that plain printing is possible
are split from the rest of HPLIP.
I even agree that those parts of HPLIP so that plain scanning is possible
are split from the rest of HPLIP.
Both splits make it possible to install HPLIP for plain printing (and optionally
additionally for plain scanning) on a server system.
Therefore openSUSE has split HPLIP into three binary sub-packages as follows:
hplip-hpijs:
The core parts of HPLIP so that plain printing is possible, see
https:/
and
https:/
hplip-sane:
What is needed in addition to hplip-hpijs so that scanning is
possible with generic scanning frontends (in particular with the
command line tool "scanimage"), see
https:/
and
https:/
hplip:
All the rest of HPLIP.
Be happy that up to now nobody had detected that one could split
HPLIP even more: Into a sub-package that contains only libraries
and one more sub-package that contains only development files
(mainly header files) and so on ad nauseam.
To mitigate possibly bad consequences of the split I have in hplip.spec
=======
Name: hplip
...
# Require the exact matching version-release of the hpijs sub-package to make sure
# to have the exact matching version of libhpip and libhpmud installed.
...
Requires: %{name}-hpijs = %{version}
# Same rationale for the sane subpackage.
Requires: %{name}-sane = %{version}
=======
to ensure the integrity of the upstream software, see
https:/
and
http://