Philip Brown wrote: > (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. >
You're taking my analogy in a different direction than intended, though it doesn't matter that much. The issue from my perspective is that merely building an executable only gets you part of the way home towards putting that executable into the hands of an actual user. The rest of the way is packaging, and I don't think they're an entirely separable problem, since without users, you're just hacking for your own amusement. Fun, but not what I'm paid to do ;-) Lots of things have entirely trivial packaging, but lots don't, so I don't think separating the two is actually useful in practive. > > 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. > Perhaps it could be, but the ARC doesn't make such decrees, at least not on its own. Somebody steps up and creates the project to do it. > 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. > Sounds a lot like the make install; make pkg split that's already used in ON and other hierarchies. > (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. > This looks like a shell game of cost-shifting; who's doing the work to realize the package in each packaging system? How does the developer get even one done to verify that he's actually got the right stuff together to produce something other than a bag of inoperable bits for a user? Dave
