>From Nicolas.Williams at sun.com Wed Feb 27 10:57:41 2008

>> Then again, if you're putting it into the proto area anyway then moving &
>> deleting I don't know why you just do the install into the right spots in
>> the first place, then delete the bits you don't want? Though perhaps
>> there's a lot more to delete individually then.
>
>Because that means knowing what those bits are.  What if the next
>version of SQLite3 installs lemon (a parser generator)?

If you're already cherry-picking what you want don't you already
have that problem? Or are you saying you _don't_ want it to install
more things like that, which you then forget to delete? Well if
you don't want to ship lemon, but it does, I'd actually side with
it as I tend to think if we claim we're shipping package 'foo' then
we really did ship everything you'd get if you built it yourself.
That's what 'we ship foo' means to me. If we delete things we don't
want then that's not 'foo' that's 'foo as modified by SMI'. At
least to me. Plus shipping everything is a safer default, fewer
'you forgot to package XXX so my life is ruined' bugs appear.

Yeah I agree with not shipping things like static libraries in
most cases, but at least that's usually controlled by a configure option.

>I'd much rather have full control over what gets installed.

You do either way :) And I'd think that this part of the work is
the easy part of doing upgrades. After all, if the Makefiles can
be told to install into $ROOT properly then pkgmk and protocmp will
notice when things are added/removed. When you have a hardcoded list you
won't know unless something is deleted, and it will still be easy
for you to miss, say, a new header file that needs to be shipped
because an existing one now requires it.

The hard part of upgrades for me is determining if there are any
incompatible changes, the paperwork, the testing...more so if anything
is using it. The packaging is pretty simple in comparison.

Of course I won't force you to do it either way, this is all just
my opinion from my minimal work in sfw.

btw your install script shouldn't really be creating the usr/lib/*
symlinks if they aren't there. You're supposed to have run
'make setup' at the top level if you're building by hand, and if
you haven't done that you should have worse problems than the
links :)

        Mike

Reply via email to