[lsb-discuss] Packaging

[Niall Walsh]

Theodore Tso wrote:
> For the LSB, though, we really need to talk about what we can achieve
> in a resonable short-term effort, and what we believe major
> distributions would be willing to ship and which ISV's would be
> willing to use in the near future.
>
> 						- Ted
>   
A package could contain the uri to a package-list which "owns" this 
package (for updates and to get actual locations for dependencies).

That package-list uri would contain a list of packages with:

name
source
depends
provides
file
uris
priority

uris and priority are arrays to match the depends.  uris allows the 
package to specify the package-list(s) to use for the depends.   
priority specifies the priority that list should have for that 
dependency, meaning that you can suggest to a package manager how this 
source should be used to resolve version differences with other packages 
of the same name.

source is the uri to the package-list for this package.   You could just 
set this field for a package-name to not include the package but 
reference another list which should be used to get it.

To install a package:
A) a package manager _could_ first check it's source for any updates
B) check all the dependencies (recursively) to determine what is 
required, fetching their uris/sources to work out their dependencies
C) install each dependency (and it's dependencies) in turn until you 
install the original package, recording each uri, package and priority 
to check for updates

A package manager should be able to allow (at users choice) the source 
information from inside packages to be used and/or an interface to 
provide extra package-lists and install packages from them?   Either way 
you don't just install a package anymore (unless it is a solo standalone 
package) but instead install a package from a list (which provides it's 
update concept).

The lsb could insist that lsb conforming packages don't use the array of 
uri's at all (or use the source field in a package list) and hence one 
uri for the package and dependencies (priorities on dependencies would 
still be nice so you can say "only install libfoo>2 from here if you 
can't get it elsewhere" where you feel libfoo is a lsb candidate for 
example).   lsb could even say that the package manager should ignore 
all priorities and automatically fulfill all dependencies with the 
package source's dependencies, so everything beyond lsb must be supplied 
and used from one list/uri/source (though leaving the possibility of 
hints so the packager could allow users who configure or choose a pm to 
do it to satisfy dependencies from another source).

If the lsb goes for mandating ultimate control (self-contained lists 
which hence have no source, uris or priority), an "lsb-get" 
program/alias which uses the underlying package manager to do the 
right/best thing should not be an excessive requirement on 
distriutions?   All the script would have to do is parse a package or 
source+package-name to get files for all the unmet dependencies 
(recursively), download the actual packages and feed them (in correct 
order/blocks) to the package installer.   It should also have update, 
upgrade and remove options to get the latest lists, install one/all 
newer installed packages and remove package(s) (with an option to also 
remove any packages installed by this package which are only required by 
this package).

If people then want to look at hooking in all sorts of alternative's on 
top of this they can go ahead, but in the meantime you can create a 
package-list for all your packages which includes all of their 
dependencies so you don't have to go statically compiling everything or 
"bundling" all of the dependencies into one package.

Niall