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: Eitan Adler on 6 Feb 2010 16:48 The recent change to jpeg required a lot of changes to a lot of ports all just to bump a version number. It is easy to miss things this way and requires a lot of work and downloading. I propose that some kind of MAJORVERSION be stored in /var/db/ports. Then when a library's MAJORVERSION is changed it will prompt a rebuild on any port that relies on it will also get rebuilt. Computer are *designed* handle these types of things _______________________________________________ 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: Edwin Groothuis on 6 Feb 2010 17:27 On Sat, Feb 06, 2010 at 11:48:33PM +0200, Eitan Adler wrote: > The recent change to jpeg required a lot of changes to a lot of ports all > just to bump a version number. That is true, there is a script for in /usr/ports/Tools/scripts/ called bump_version.pl which can do most of the magic. > It is easy to miss things this way and requires a lot of work and > downloading. Oh, you are talking about the user side of things. Please have a look at portmaster or portupgrade, they can do this magic for you. > I propose that some kind of MAJORVERSION be stored in /var/db/ports. Then > when a library's MAJORVERSION is changed it will prompt a rebuild on any > port that relies on it will also get rebuilt. I like the idea, but it handles the problem from the wrong side: The person who bumps the port revisions would need to have all ports installed to make this judgement. > Computer are *designed* handle these types of things See first two comments. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin(a)mavetju.org Weblog: http://www.mavetju.org/weblog/ _______________________________________________ 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 02:32 On Sun, Feb 7, 2010 at 12:27 AM, Edwin Groothuis <edwin(a)mavetju.org> wrote: > On Sat, Feb 06, 2010 at 11:48:33PM +0200, Eitan Adler wrote: > > The recent change to jpeg required a lot of changes to a lot of ports all > > just to bump a version number. > > That is true, there is a script for in /usr/ports/Tools/scripts/ > called bump_version.pl which can do most of the magic. > I didn't know that - this solves /most/ of the issue. > > > It is easy to miss things this way and requires a lot of work and > > downloading. > > Oh, you are talking about the user side of things. Please have a > look at portmaster or portupgrade, they can do this magic for you. > > No, I am talking about the committer's side of things. It is easy to miss a port that depends on the library your changing. > > > I propose that some kind of MAJORVERSION be stored in /var/db/ports. Then > > when a library's MAJORVERSION is changed it will prompt a rebuild on any > > port that relies on it will also get rebuilt. > > I like the idea, but it handles the problem from the wrong side: > The person who bumps the port revisions would need to have all ports > installed to make this judgement. > Why? This would be done at the same time that bumping revisions would have been done, _______________________________________________ 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 06:56 On Sat, 6 Feb 2010 23:48:33 +0200 Eitan Adler <eitanadlerlist(a)gmail.com> articulated: > The recent change to jpeg required a lot of changes to a lot of ports > all just to bump a version number. > It is easy to miss things this way and requires a lot of work and > downloading. > > I propose that some kind of MAJORVERSION be stored in /var/db/ports. > Then when a library's MAJORVERSION is changed it will prompt a > rebuild on any port that relies on it will also get rebuilt. > Computer are *designed* handle these types of things This will accomplish exactly what you want: portmanager -u -p It is in the port tree. -- Jerry gesbbb(a)yahoo.com |::::======= |::::======= |=========== |=========== | We are not a clone. _______________________________________________ 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 08:30
> This will accomplish exactly what you want: > > portmanager -u -p > How will portmanager -u -p avoid the need to bump the PORTREVISION (like the recent jpeg change)? > > It is in the port tree. > > -- > Jerry > gesbbb(a)yahoo.com > > |::::======= > |::::======= > |=========== > |=========== > | > > We are not a clone. > > _______________________________________________ > 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" > _______________________________________________ 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" |