On Mon, May 07, 2007 at 03:35:48PM -0500, Jeremy Messenger wrote: > On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway <[EMAIL PROTECTED]> > wrote: > > >On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: > > > >>>No, at a minimum I am not comfortable recommending its use until it > >>>saves old shared libraries across updates (I sent you email about this > >>>a while ago), which is a vital safety and robustness mechanism. > >> > >>I am one of people that dislike this and it is not required to get build > >>function. ;-) I think this option should be disable by default, because > >>put stuff in lib/compat/pkg hides the problems. Also: > > > >No, it is required when dealing with shared library bumps (which > >happen about once a week). Otherwise all of the installed ports using > >the library break if the new library build fails. Talk to Brooks > >about how annoying this is with e.g. gettext. > > portmaster has a feature to backup the old package before the upgrade. I > think it is better than put in lib/compat/pkg. When I used portupgrade and > I always have lib/compat/pkg disabled until I switched to portmaster. I > never have that problem when ports tree is flexible enough to downgrade > and wait until someone fix it.
Well, is this feature enabled by default and does it completely back out the upgrade if it fails? I may be wrong, but I doubt it is going to do a complete recursive backout of the upgrade if e.g. one of the ports depending on the new library fails to build after the library was updated. If it just restores the old version of this port then it will be restoring a nonfunctional port, since it links to the version of the library that was already deleted. The issue is about providing seat-belts for our users who just want failed upgrades not to destroy their system. Even if you think that backing up the package is a better solution than preserving the shared libraries, it seems to me that portmaster still falls short here because it doesn't provide a rollback mechanism to restore the system to a working state when an upgrade fails. > >I dispute the correctness of this entry. The old libraries in > >lib/compat/pkg are not linked to directly by new builds. The only > >situation in which something might end up being linked to 2 versions > >of the library is if it pulls in a library dependency from an existing > >port that is still linked to the old library. In this situation the > >build would be broken with or without lib/compat/pkg (in the latter > >case, you have an installed port linked to a library that is entirely > >missing, so that port will be nonfunctional). > > > >Kris I guess your silence means you agree with me here :) Kris _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
