[arc-discuss] [sysadmin-discuss] [install-discuss] Seeking early guidance for integrating a new package system into O/N. (conary)

[Philip Brown]

(removed pkg-discuss, at the request of various people...)


Dave Miner wrote:
> 
> Packaging is not a leaf node in the system where changing it impacts 
> almost nobody else.  Supporting multiple packaging systems is close to 
> the same impact throughout a development and user space as supporting 
> multiple incompatible kernels, compilers, or libc's.  Yeah, you can do 
> all of those things, but everyone pays.

I would have to disagree here.
First of all, show me how many binaries from the source tree, in any way 
function differently, depending on what packaging mechanism delivers them to 
the disk? !
A comparison to multiple kernels or libc's, is off base.


As far as impact to developer support effort required:
  There are ways that you can do it, without noticably increasing required 
effort by any of the interested parties, once standards are set.
If the ARC board decrees, for example, that it is an EXPLICIT GOAL of 
opensolaris, to be friendly towards multiple packaging systems; then it is 
possible to define a generic Binary->Package API.

For example, every clump o' software in the src tree, could then be required 
to support some kind of
  "make pre-package" target, which would copy the binaries and assorted 
files, to some understood hierachy, such as $DESTDIR(reloc-root)/blahblah.
Additionally, there would be an agreed-upon location and format of files to 
hold meta-data, such as description, version, etc, etc.

It would then be up to a specific packaging system, to go through the tree, 
and do "make pre-package" for the software it wished to include, and then do 
the binary -> package translation, appropriate to that packaging system.

(IPS actually does this in some sense already; it just uses an implicit, 
rather than explicit, API; it goes through the SVR4 pkg metadata, for 
packages that are referenced under  pkg/gate/src/util/distro-import/, etc)

Such an API, would seem to me to only require an O(N) level of effort, 
reguardless of how many different packaging systems the community was 
interested in using around opensolaris.
And the "N" here, is a very small "N", to boot ;-) For any particular clump 
of software in the source tree, it seems to be about equivalent effort to 
support a single generic binary->package API, as it would be to support an 
individual, specific packaging system.


One might say that there is a "de facto" standard of such an API already in 
place, implemented, and in use. It would just remain for the ARC to 
formalize the API to some degree, and to formally make the statement that it 
is an opensolaris goal to be friendly to more than just one packaging system.