better way to handle required rebuild on library bump
in [Ports]
|
Prev: samba34 fails building on FreeBSD 8.0-STABLE: Compilinglib/memcache.c, lib/memcache.c:29: error: expectedspecifier-qualifier-list before 'uint8'
Next: FreeBSD unmaintained ports which are currently marked forbidden
From: Buganini on 7 Feb 2010 08:47 I thought about this during last jpeg update: http://www.mail-archive.com/freebsd-ports(a)freebsd.org/msg22476.html http://www.mail-archive.com/freebsd-ports(a)freebsd.org/msg22501.html but this need non-trivial work on mk, and somebody may consider it too complicated. --Buganini _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Jerry on 7 Feb 2010 10:44 On Sun, 7 Feb 2010 15:30:29 +0200 Eitan Adler <eitanadlerlist(a)gmail.com> articulated: > How will portmanager -u -p avoid the need to bump the PORTREVISION > (like the recent jpeg change)? From your original post: <quote> Then when a library's MAJORVERSION is changed it will prompt a rebuild on any port that relies on it will also get rebuilt. </quote> I assumed that you were looking for a program that would force an update of any ports that were dependent upon a changed(updated) port. The command I posted would do that. Perhaps I am just not fully comprehending what you are attempting to accomplish. I have as of yet to not found any other port management program that accomplished that as fully as 'portmanager' does. -- Jerry gesbbb(a)yahoo.com |::::======= |::::======= |=========== |=========== | When people have trouble communicating, the least they can do is to shut up. Tom Lehrer _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Eitan Adler on 7 Feb 2010 12:37 > <quote> > Then when a library's MAJORVERSION is changed it will prompt a rebuild on > any > port that relies on it will also get rebuilt. > </quote> > I assumed that you were looking for a program that would force an > update of any ports that were dependent upon a changed(updated) port. > The command I posted would do that. Perhaps I am just not fully > comprehending what you are attempting to accomplish. > I've been using portmaster since I started using freeBSD (about 2 and a half years ago) ;) My post was a way to deal with things like the recent jpeg update in a more efficient manner. Instead of the port committer having to bump the portrevision of each port that depeneds on jpeg they could just bump MAJORVERSION in jpeg and have the rest of the work done magically _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: "b. f." on 7 Feb 2010 16:44 >I've been using portmaster since I started using freeBSD (about 2 and a half >years ago) ;) >My post was a way to deal with things like the recent jpeg update in a more >efficient manner. Instead of the port committer having to bump the >portrevision of each port that depeneds on jpeg they could just bump >MAJORVERSION in jpeg and have the rest of the work done magically I don't see how this would be better. (Maybe if you showed us an implementation it would be clear?) There has to be a mechanism for tracking port version numbers in either case. The current method relies on this existing mechanism to prompt people to upgrade dependent ports after a shared library version bump, and this process is automated, via a script. (The script could be improved, if necessary, or it could be more closely integrated with commits, so that it is run automatically.) The committer has to make some changes to dependent ports in either case, because the requested library versions in some LIB_DEPENDS lines will need to be adjusted. Perhaps if the version requirements in these lines were relaxed or removed, fewer ports would have to be changed, but that could also be a source of problems. In any event, at the moment, there is not a great deal to be gained by avoiding bumping the PORTREVISION numbers, because these other changes need to be made anyway. And if I recall correctly, this has not been the major source of problems for users in recent large updates, anyway. You seem to be suggesting a different, parallel mechanism for updates. In order to do this, you'd have to augment and change the ports infrastructure, the base-system package tools, and probably third-party management tools like portupgrade and portmaster, while maintaining backward compatibility with older binary packages. And you'd have to give people a chance to opt out: they may not _want_ to rebuild every dependent port, but only some of them. Under the current system, they can do as they please. _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Doug Barton on 7 Feb 2010 17:18
With due respect to the creativity of the OP, the whole conversation is basically moot since in almost all cases a library major version change requires a change to the LIB_DEPENDS line in the port anyway, so a PORTREVISION bump is a very tiny bit of additional work. And I agree with b.f., without actual code to review it's hard to have an intelligent conversation about this. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org" |