> Dennis Clarke writes: >> The other issue that arises here is that a patch has a dependency tree >> also. >> If I have a package that requires only a few small changes then a patch >> makes sense. If I then make another release with a few more changes then >> we >> have yet another patch. However these patches now depend on previous >> editions of the patch. In order to get an upto date Apache we need the >> patch >> "today" to include all the patch changes from previous patches in a >> summative way ( if there is such a term ) and we need to be able to go >> from >> a five year old Apache to todays Apache in one fell swoop with the grand >> unified patch. > > Right; you would need to deal with the complex and undocumented issues > related to patching. > > I would not recommend attempting to deliver these things by way of > patches. > > The original question, though was about whether Sun uses patches to > avoid the package remove/install design pattern, and that's not quite > the case.
We do have a good line of discussion here that needs to be looked at. Or at the very least we can draw things on a whiteboard and see if there if a Grand Unified Theory of package maintainance where we respect the old rules ( like Newtonian Physics ) but also handle a better way of thinking, like Quantum Physics. I just hope that we don't end up looking for Schodingers cat and then find out that the patch worked and the cat is in fact, quite dead. I have no idea if anyone can follow my puns so I'll be more clear. Do you feel or even think that we can come up with a way to maintain the contents database file as well as perhaps design a better way to roll out software packages? That is a loaded multi-level sort of question and a good way to start. Dennis _______________________________________________ opensolaris-discuss mailing list [email protected]
