On Wed, Feb 27, 2008 at 11:17:34AM -0800, Mike.Sullivan at sun.com wrote: > >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
No, because the things I want are stable -- they won't go away. > more things like that, which you then forget to delete? Well if That, yes. > 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. But I think that's something the next integrator needs to be on the hook for. > Yeah I agree with not shipping things like static libraries in > most cases, but at least that's usually controlled by a configure option. Right. In this case there's an option for it, but it doesn't work (i.e., configure takes a --disable-static option, but the makefile doesn't honor it). > >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. I still have the problem that I have to run *two* configure && gmake installs, one for 32-bit and one for 64-bit and I don't want to have to make sure that they don't step on each other (there's lots of paths to check). Folks, I'm trying to make things simple. And all I see is complications arising here. I find it a lot simpler to install into a tmp DESTDIR and cherry pick. I'll stick with it unless someone pulls rank (Mike, I guess that'd be you :) > 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. OK, so I'll keep it using tmp DESTDIR. BTW, I've put many hours into trying this various ways, and over the weekend too. I really, *realy* don't want to experiment anymore before integrating. Think of future volunteers. > 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 :) OK.
