Re: Packaging stuff
"Anthony W. Youngman" wrote:
> in other words, an LSB-compliant application *must* be completely self
> contained for anything over and above the LSB. So if several apps all use
> the same library, there will be one copy on the system for every app :-(
I had missed this point. That's why we don't need a standardized list
of package names for packages intended to be installed on any LSB-compliant system:
nothing will ever depend on them, and they will not check any dependances
except those defined in the LSB. (More or less. You can imagine someone
shipping an app that consisted of several packages which depended on
each other in some way, and used RPM's dependency checking to enforce that.
Is that allowed?)
> have you ever installed a complicated database, that
> *needs* to stuff daemons, libraries, runtimes in all the relevant places?
> You may well have, I certainly have, and I think the LSB's approach might be
> a tad too simplistic here... surely a database server will NOT be LSB
> compliant, because the admin will have installed it headless without X - or
> are you expecting us to emulate the Windows habit of buying overspec'd
> hardware in order to install software we have no use for :-)
This is a good point. If the LSB defines only a single pseudopackage,
lsb-1.0
as the thing apps should depend on, that prevents us from properly
representing "a headless but otherwise LSB system".
Presumably the LSB will also define more fine grained pseudopackages, e.g.
lsb-posix-1.0
lsb-fhs-1.0
lsb-x-1.0
etc. to support things like headless systems (which would have lsb-posix-1.0
and lsb-fhs-1.0 'installed', but not lsb-x-1.0).
(I'd check whether this is already done, but linuxbase.org is down for me at moment.)
- Dan
Reply to: