[lsb-discuss] Adding dependency on "lsb" causes huge downloads

Craig Scott audiofanatic at gmail.com
Thu Feb 25 00:26:26 PST 2010

[NOTE: Apologies if this makes it to the list twice. I sent it from the 
wrong email address the first time.]

There's another option to consider, one which could be considered
complimentary rather than an alternative. The LSB already uses RPM as
it's packaging system, so is it possible to improve/use RPM itself to
work out package dependencies based on actual files that need to be
present rather than higher level package names? As Till states, distros
give differing names to packages, so as an ISV, I can't reliably put
package names as dependencies in our RPM's. What I can do, however, is
provide a list of files (typically libraries and/or executables, but
could also be other things) which must be present in order for my
package to function properly. RPM should know whether any installed
packages already provide these and most packaging systems could probably
be augmented to find such dependencies if they don't already have this
capability (but I'm more than happy to be corrected on this!). I believe
RPM already has some mechanisms for detecting at least required
libraries when the package is built and maybe already has enough to
support this approach without any further changes (or at least enough to
be useful).

On thing that might be missing is a convention or common practice of
package builders specifying the files they need. If RPM can reliably add
dependencies for some things (eg libraries), then at least some part of
that is automated and then package builders only need to worry about the
things RPM cannot detect (data files, headers for devel packages, etc.).
Note that not all dependent files would necessarily have to be specified
- it may be enough to specify the main libraries and then expect any
other associated files that would typically be part of that package to
also be present. Note that this is no less robust than is already the
case when specifying packages simply by their high level package names.

Another useful area might be for the LSB to give some guidance on naming
conventions for certain classes of packages. The -devel convention used
by some distros is one example. Even if a distro uses a different
convention, it should be trivial for them to provide LSB-compliant
package names that simply pull in the equivalent package for that
distro. Not sure how useful that would be. It would probably depend on
how far the LSB guidance went.

On 02/25/2010 08:46 AM, Till Kamppeter wrote:
>  As the names of the packages and the splitting into subpackages differs
>  from distro to distro, one should try to find out which exact packages a
>  package depends on, but better divide up the LSB in something like 10-15
>  areas, like "lsb-server", "lsb-desktop", "lsb-printing", "lsb-mail", ...
>  and allow developers who publish their software as LSB packages to let
>  the package depend on the needed modules. So for example a printer
>  driver will only depend on "lsb-printing" and "lsb-core" and so neither
>  pull an MTA nor GUI libraries.
>       Till
>  On 02/24/2010 09:52 PM, Dan Kegel wrote:
>>  Wichmann, Mats D<mats.d.wichmann at intel.com>    wrote:
>>>  I could see a workflow that went:
>>>  1. port software
>>>  2. build package, depending on LSB
>>>  3. run checker, which gives you the "true" component list
>>>  4. update package description and rebuild
>>>  5. check once more to make sure it came out right
>>>  Would that be terrible?
>>  Yes, except that it's kind of impossible to get right,
>>  so the workflow should include a manual fixup step
>>  and/or provide a way to figure out the needed "true"
>>  components without the checker.

Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

More information about the lsb-discuss mailing list