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

[Helbling, Douglas E]

This "use RPM more effectively" suggestion sounds good on the surface.  But I thought that LSB was supposed to actually make things better/easier ... sorry, just being MILDLY facetious.  In all seriousness, this is a big issue.  Using RPM to help solve this may be a partial solution, but the extra issues with Debian/Ubuntu and deb packages make it even stickier.  Perhaps some form of task team could be assembled to take this on and craft some solution proposals, as I doubt we can solve this via email exchanges alone.

- Doug Helbling 
  Intel TSRD    

 
-----Original Message-----
From: lsb-discuss-bounces at lists.linux-foundation.org [mailto:lsb-discuss-bounces at lists.linux-foundation.org] On Behalf Of Craig Scott
Sent: Wednesday, February 24, 2010 2:30 PM
To: lsb-discuss at lists.linux-foundation.org
Subject: Re: [lsb-discuss] Adding dependency on "lsb" causes huge downloads

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

_______________________________________________
lsb-discuss mailing list
lsb-discuss at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss