Dave Miner wrote:
> Philip Brown wrote:
>>
>> 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.
I confess to not being familiar with that current process; I suspected that
it might have been the case, but I dont know where to start looking on docs
for that.
>...
>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?
I would say:
1. The people "maintaining each packaging system", are responsible for
making mappings from each [generic-API package] to [specific packaging
system package]
2. One way the developer knows he's got "the right stuff", would be because
he picks his favourite packaging system of choice, does the equivalent of
"cd {packagingsystem-base} make mypkg ", and see if he gets something that
works. If it works for one, it should work for all, so long as his favourite
packaging system sticks strictly to only using the API.
ORRR, if the "generic binary->package API" is a declared to be
[a specifically defined subset of the existing SVR4 pkg spec] that is
already part of ON builds, etc:
he could more simply do your above-referenced "make install; make pkg", and
sees if he gets a viable SVR4 pkg.
If he gets a working one, then that in itself should be proof that it is
compliant to the "specifically defined subset" comprising the generic API.
