[lsb-discuss] Packaging, dependencies and klik

[Niall Walsh]

Only subscribed so please forgive the new thread.

I would like to see the lsb add a package-list section, so that a 
package could supply package-lists (including uris to other lists with 
weights) and uris could supply standalone lists.   The default behaviour 
to use the package should be regarded as to install the package and to 
use the package-list information to satisfy any dependencies.   In 
practice this would create a mess if a native package manager started to 
mix sources like this, however they should (by default) only use the 
package-list to satisfy dependencies they can't meet themselves.   
Extend the use of the package name fields in the dependency info, or 
adding another array so you can pin a dependency to a package-list 
(native pm should warn if installing something from outside especially 
if it has it's own version).

lsb could produce a global package dependency map which would allow the 
package to simply state it's dependency information in terms of a global 
set of names, and then each distribution could have it's own map to do 
any rewriting they need to.   Even if the distributions did not include 
this, using a distributed method I'm sure this information could be 
unofficially maintained reasonably.

The goal would be that all packages would simply list packages in the 
lsb dependency map as their dependencies and that native package 
managers would convert them into the local preferred packages, but any 
package would still be free to try and pull in any other packages (by 
name, version and/or source) as dependencies and it would be up to the 
package management software to "do the right thing" the package just 
gives it more information.

Why did I mention klik in the Subject?   A combination of a bit of full 
disclosure and that this would suit klik perfectly as a "secondary 
package manager" (klik is not a package manager).   Klik could easily 
use this information to supply packages against lsb (once the package 
itself had sensible information the distribution support would not 
matter).   However I think what I have outlined is a good general approach?

 From the native package managers perspective of trying to interact with 
a secondary package manager, communicating the above would allow each 
package manager to inform the other of what packages it has installed 
and/or knows about, optionally (as proposed elsewhere) along with it's 
files manifest (perhaps with information on what is a program,  config 
file, documentation, src) and also with an  optional block to provide 
information on how to install, upgrade and remove the package (this is 
at the level above using the packaging mechanism itself to do it,  but 
using the package manager which installed it to do it).   What either 
side chooses to do with what it is told is another matter.

Another nice feature would be to also include the possibility of having 
full source build dependency trees for the package (both to rebuild 
against the newest suitable libraries and to recreate the original 
package's files, can't see many ISV's using this bit though).

The burden remains on any "package manager" which wants to potentially 
conflict with a greater system (including doing any translation on a 
foreign package) to know what it is doing, play safe and obey the user, 
though if the package is being directly installed by the native package 
manager it could be able to monitor many problems (though by default by 
probably making only very clean packages installable).   If a package 
(or alternate package manager) wants to plug in it's own "package 
manager/installer" into the real package management system, the real 
package manager will only have to allow programs to register packages 
along with the hooks to install/remove/upgrade (but as I said, a nice 
package would do more and a nice native package management system 
probably won't do it by default).

A whole aspect of this I haven't mentioned up to now but I think this 
would cover is user installation.   Ideally a package manager would 
allow the user to act as root of their own home and install (non-root) 
programs on top of the native package manager using a user package 
manager.   The above would allow the users package managers to know what 
was installed on the system (but not be able to alter it) and install 
the packages into the users home rather then system wide and it could 
even let other packages native installers register the package with the 
user package manager rather then the system package manager so they 
would have a one stop shop to administer their own packages.    It could 
(transparently) allow the users to install available packages system-wide.

Nice packages could then be constructed which could be installed by a 
supporting native package manager, by their own "package manager" 
(perhaps an optional self-install field in the package) or by a third 
party package manager.   A distributions own packages might simply point 
back to the uri for their own package lists while an "ISV" (or others) 
might include an lsb list, distribution lists and it's own custom list 
so it should be installable anywhere (reasonably).

I hope the above makes some sense and offers another opinion to help 
others construct some ideas, just as many of your mails and thoughts 
have helped form some of these over the last few days.  Obviously they 
still are far from 100% formed!

Niall Walsh