> (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.
excellent observation. One key problem down the road is how to patch that software and in that case we do have a problem with how the software patch gets delivered as well as how the patch affects other software components. The "how" can be elegant and only update the minimal number of files or even fragments of files in a given system or it may be ham handed and simply rip and replace entire software trees to update a single file. The various package delivery mechanisms must be sensitive to the initial install process as well as the long term maintenance vision. I think that the interaction of every binary with every dependency and every lib required leaves O[N] and becomes a P versus NP problem. Sort of the traveling salesmen that must visit a multitude of cities with a multitude of specific customers in each city. This is just me and my white board talking but I'd like to think we can devise something elegant. > 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. I'm somewhat conservative here and I think that the community maintainer should be required to do the minimal work possible. Just build it and ensure it links to the *current* set of dependencies and then the task of delivery to the end user should be left to a software package infrastructure. Essentially unload the community maintainer such that he/she can just participate as opposed to enter a slave race. > 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. Sounds like utopia. Let's do that :-) but I have no idea how. > 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. That would be the package delivery engine that kicks into gear after the community maintainer does their build bits. We clearly need a QA phase and test report phase. No more of this "code review" email stuff that clearly never results in anyone actually running the end result in a real world test. > 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. Sounds great .. yes. > (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. What about patches ? > 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. This defacto standard that you speak of .. am I familiar with it? :-) Dennis Clarke
