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

Wichmann, Mats D mats.d.wichmann at intel.com
Wed Feb 24 12:09:54 PST 2010


lsb-discuss-bounces at lists.linux-foundation.org wrote:
> lsb-discuss-bounces at lists.linux-foundation.org wrote:
>> Chromium recently tried switching to using a dependency
>> on 'lsb' ... and it pulls in everything under the sun, even
>> an MTA.  This caused our users to yell.  We're reverting the change.
>> 
>> One of the goals of the 'lsb' dependency was to make
>> life easier for developers, but when our users yell at
>> us for using it because it causes all sorts of possibly
>> harmful crap to be installed, that's not making life easier.
> 
> well, the purpose of the dependency is to make sure the
> entire environment implied by 'lsb' is available to apps.
> if it's NOT pulled in, and the app expects something to
> be there that isn't, you'd have a lot of screaming too.
> 
> if the packaging choices are inefficient and cause more to
> be pulled in than needed, I'm afraid we can't do a lot about
> that from the LSB workgroup side, but maybe some hints to the distros
> would help? 


Let me continue to go off on a bit of a tangent, or let's
say, a little bit of speculation.

The LSB spec itself certainly has the opportunity to expose
a lot more granularity for applications to depend on.  We
were headed in a direction that had *some* granularity
(where >1 = some), but that was stopped because it had the
potential to be "too confusing".  But if we believe that in
2010 and beyond, all installations will happen in the presence
of the repository context, rather than the package context
(see footnote - this may not be true), would that still be the
case?  If there were a tool available that determined the
necessary LSB component-level dependencies so you could put
them into your package description, and you assume that at
install time the distro's repository is available to resolve
those, do we still have to stop at only one single 'lsb'
meta dependency?  Could we have greater granularity,
allowing only some distro packages to be pulled in on any
given LSB-package install, and lighten the burden Dan refers
to in the original message?

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?


Footnote:  I'm not convinced that the installation context
will always include distro's repository, such that there's
automatic dependency resolution and installation as needed
of missing distro packages.  I can see the proliferation of
"App Stores" actually making that less likely than it is
today.  But I have no specific knowledge one way or the other.


More information about the lsb-discuss mailing list