John Levon wrote:
>> And here's where we really come to the crux of the philosophical
>> differences between JDS and the rest of the Solaris organisation,
>> especially but not only ON. The procedure you're describing is one
>> which asserts that "upstream is assumed to be correct" and if in
>> doubt, the effects of using the autotools-based build system are
>> assumed to be desirable. That's perfect for compiling what the GPL so
>> eloquently terms "mere aggregations" of software, but it's dead wrong
>> for building a tightly integrated polished product.
>
> Isn't it better to fix upstream where possible than continue to apply fixups
> until the end of time? Sure this might not always be possible, or feasible,
> but
> it has to be better than not trying.
yes of course it is. And some folks do that, which is great.
>> And if we know what we're shipping,
>> is it so much to ask that we explicitly specify it (in packaging
>> files, if not in install-sfw or equivalent)
>
> I think explicitly specifying things is a reasonable burden. The problem with
> not using "make install" is it's so error-prone
The install script approach is there to give you the flexibility to
install however you like or can. There are suggestions on what you
could do, and you can look at what others did (which did not all
name their install scripts install-sfw, and there are both bad and
good results from that).
There is no ban against using 'make install DESTDIR=$ROOT/nifty_place'.
There is only the observation that not all packages respect a Makefile
variable like DESTDIR and insist on dropping files live on the build
machine, so you need to make sure it works properly rather than just
use it and assume. Heck, even some that seem to might have possible
nasty consequences - this one wasn't nasty but it was fun to find during
the non-root build work:
6407776 papi install-sfw script touches a file on the build machine
and when you have many people building the consolidation on the same
machine (as root before) you don't really want them writing over each
other and getting strange build failures or corrupt binaries.
Some packages have gotten better over time and so perhaps the
way they install can be changed. But that requires somebody to care
and go do it, so feel free :)
> With a "make install" based approach, it seems a lot easier, and a lot less
> error-prone, to verify that any changes we need to make are still valid, and
> that we're correctly picking up what upstream ships; this remains true (IMO)
> even if pkgdefs is hand-crafted.
I actually like the hand-crafting of the pkgdefs just because it seems
a good place to make you think about what you're shipping. Or at least
it seems that way to me. The bit I would like automated is the
population of the source areas (the DISTDIRS.sfw file and friends).
It is not automated now only because long long ago when I was setting
this up I couldn't get something simple to work quickly so I just
went with the simple file approach populated by a couple find's. Nobody
seems to have automated it since either so it didn't seem to be that
annoying. But again, feel free :)
Mike
