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

Tobin Davis gruemaster at gmail.com
Thu Mar 4 14:23:43 PST 2010


On Thu, 2010-03-04 at 21:51 +0000, Anthony W. Youngman wrote:
> Adding my two-pennorth, as someone who has ALWAYS right from the
> start 
> fought for granularity, this "pulls in the everything including the 
> kitchen sink" has the ability to be a *real* pain.
> 
> Okay, this dates it as a *long* time ago, I once tried to install a 
> minimal SuSE system. It *insisted* on installing ISDN support as part
> of 
> the base dependencies, despite me having only network connectivity. 
> Doesn't sound bad, except that that one package alone chewed up 1% of
> my 
> hard disk. (I said it was ages ago - it was a 600Mb hard disk :-)
> 
> But bloat is bloat is bloat. I'm typing this message on my *main* pc
> - 
> more than powerful enough for what I want. But I can't upgrade my ram
> - 
> it's maxed out at 3x256Mb. The bios can't handle disks bigger than 
> 128Gb. The processor is underclocked because the mobo FSB is 100MHz
> and 
> the processor is a 133MHz FSB.
> 
> But at the end of the day, this is my biggest frustration with the LSB
> - 
> I *don't* *want* stuff on my system that I *don't* *need*. And one of 
> the reasons I don't want it is that it is a security risk! If I don't 
> want it, it's probably because I don't understand it. If I don't 
> understand it, I don't know how to secure it. And if I can't secure
> it, 
> how do I know it won't do things I don't expect and let somebody into
> my 
> system?
> 
> Oh - maybe we can take a leaf from gentoo. I think it's pretty
> recent, 
> but they've added an awful lot of meta-packages to do with KDE
> recently. 
> Can't we define the lsb "packages" as a tree - if you ask for "lsb"
> you 
> get the lot, but that includes eg "lsb-print", "lsb-mail" etc, and 
> lsb-mail might include "lsb-mail-client", "lsb-mail-server" etc etc.
> 
> Cheers,
> Wol
> -- 
> Anthony W. Youngman - anthony at thewolery.demon.co.uk

If I can expand on this bloat issue, part of being LSB compliant from a
distribution point of view is ensuring that all of the libraries and
tools that make up the LSB spec be available, not necessarily installed.
As we start getting into smaller systems (netbooks, UMPC's, smart
phones, etc), drive space will be at a premium, especially systems
running from SSDs.  If an application developer creates an application
that requires a few specific LSB libraries, it should be up to his
installation mechanism to at a minimum check for the required libraries
or, as was the case in several apps I have seen, provide their own LSB
compliant copies and install them with their app if the distro doesn't
have it installed.

Currently, ARM as a platform is not supported by the LSB, but this
should be addressed soon, as that market is edging into the mainstream
computing marked with the latest smart phones (Android, Nokia) and a
slew of netbooks coming out of CES.  These systems are going to be
limited in what they can install, but developers will want to ensure
their development environment is at least compliant and compatible, and
their final product can be installed smoothly with minimal unnecessary
overhead.

Desktop and server systems can afford to waste space with unneeded
libraries, as a full install of, say, Ubuntu x86_64 would take ~20G.
Not much considering how hard it is to get a drive smaller than 160G,
and 500G drives are ~$60.  But on the netbook and smartphone market,
you're looking at 8-16G drives on average (not counting the Windows
Certified system requirements).

Tobin Davis



More information about the lsb-discuss mailing list