http://alioth.debian.org/download.php/* links generate redirect to http://alioth.debian.org/frs/download.php/* Ports affected: graphics/sane-frontends misc/pinfo mail/libpst How-To-Repeat: make fetch
Responsible Changed From-To: freebsd-ports-bugs->lippe I'll take it.
Hi all, Please consider this patch with minor changes: http://people.freebsd.org/~lippe/logs/ports_121884.diff Thanks! -- lippe@FreeBSD.org Felippe de Meirelles Motta
Just curious, why bump PORTREVISION of sane-frontends? If you have this port already installed, this does not change much for you. -- << Marcin Cieslak // saper@system.pl >>
Em Sat, 22 Mar 2008 17:35:00 +0100 Marcin Cieslak <saper@SYSTEM.PL> escreveu: > Just curious, why bump PORTREVISION of sane-frontends? > > If you have this port already installed, this does not change much > for you. Hi Marcin, Really it is an good question that I did have doubt too. Reading an little I found that's needed bump PORTREVISION because I have changed pkg-message to FILESDIR. I moved pkg-message because we have an patch (see projects ideas page) to print output always that pkg-message.in (on FILESDIR) exists. As described on The Porter's Handbook, we should bump PORTREVISION in this cases: 1) Addition of patches to correct security vulnerabilities, bugs, or to add new functionality to the port. 2) Changes to the port Makefile to enable or disable compile-time options in the package. 3) Changes in the packing list or the install-time behavior of the package (e.g. change to a script which generates initial data for the package, like ssh host keys). 4) Version bump of a port's shared library dependency (in this case, someone trying to install the old package after installing a newer version of the dependency will fail since it will look for the old libfoo.x instead of libfoo.(x+1)). 5) Silent changes to the port distfile which have significant functional differences, i.e. changes to the distfile requiring a correction to distinfo with no corresponding change to PORTVERSION, where a diff -ru of the old and new versions shows non-trivial changes to the code. Soon, I think that item 2 told me to bump it. -- lippe@FreeBSD.org Felippe de Meirelles Motta
Felippe de Meirelles Motta wrote: > Em Sat, 22 Mar 2008 17:35:00 +0100 > 2) Changes to the port Makefile to enable or disable compile-time > options in the package. Felippe de Meirelles Motta wrote: > Soon, I think that item 2 told me to bump it. > Hm if I read your patch correctly you do not add any new functionality (or compile-time option) for this port this time. This is a pure cosmetic change - using another (newer) mechanism to replace PREFIX in the file. For the user there should be no visible difference at all. The main purpose of the PORTREVISION is to tell existing users of the same PORTVERSION - "folks, it's worth upgrading this time, we fixed serious stuff". Therefore I would advise no to bump the PORTREVISION. I think our discussion time could be better used upgrading libpst port to the 0.5.2 release:-) -- << Marcin Cieslak // saper@system.pl >>
Em Mon, 24 Mar 2008 14:30:28 -0800 Gábor Kövesdán <gabor@kovesdan.org> escreveu: > > > Really it is an good question that I did have doubt too. Reading an > > little I found that's needed bump PORTREVISION because I have > > changed pkg-message to FILESDIR. I moved pkg-message because we > > have an patch (see projects ideas page) to print output always that > > pkg-message.in (on FILESDIR) exists. > > > > As described on The Porter's Handbook, we should bump PORTREVISION > > in this cases: > > > > 1) Addition of patches to correct security vulnerabilities, bugs, > > or to add new functionality to the port. > > > > 2) Changes to the port Makefile to enable or disable compile-time > > options in the package. > > > > 3) Changes in the packing list or the install-time behavior of the > > package (e.g. change to a script which generates initial data for > > the package, like ssh host keys). > > > > 4) Version bump of a port's shared librarty dependency (in this > > case, someone trying to install the old package after installing a > > newer version of the dependency will fail since it will look for > > the old libfoo.x instead of libfoo.(x+1)). > > > > 5) Silent changes to the port distfile which have significant > > functional differences, i.e. changes to the distfile requiring a > > correction to distinfo with no corresponding change to PORTVERSION, > > where a diff -ru of the old and new versions shows non-trivial > > changes to the code. > > > > Soon, I think that item 2 told me to bump it. > > > Yes, you're right, PH says that, but personally I think that a > PORTREVISION bump is not needed in this case. It's true that you have > changed the install-time behaviour, but you don't need to make the > users upgrade the port just because of the new pkg-message. As they > have the port installed, we can suppose that they don't need those > instructions now. > > Gábor Right, I "fixed" it now. Marcin, doesn't have an new version for libspt, see: root@shire: /home/ports/mail/libpst# make extract ===> Extracting for libpst-0.5.2 => MD5 Checksum OK for libpst-0.5.2.tgz. => SHA256 Checksum OK for libpst-0.5.2.tgz. root@shire: /home/ports/mail/libpst# ls work/ .extract_done.libpst._usr_local libpst-0.5.1 I did make an diff between these versions, but no changes. -- lippe@FreeBSD.org Felippe de Meirelles Motta
> Really it is an good question that I did have doubt too. Reading an > little I found that's needed bump PORTREVISION because I have changed > pkg-message to FILESDIR. I moved pkg-message because we have an patch > (see projects ideas page) to print output always that pkg-message.in > (on FILESDIR) exists. > > As described on The Porter's Handbook, we should bump PORTREVISION in > this cases: > > 1) Addition of patches to correct security vulnerabilities, bugs, or to > add new functionality to the port. > > 2) Changes to the port Makefile to enable or disable compile-time > options in the package. > > 3) Changes in the packing list or the install-time behavior of the > package (e.g. change to a script which generates initial data for the > package, like ssh host keys). > > 4) Version bump of a port's shared librarty dependency (in this case, > someone trying to install the old package after installing a newer > version of the dependency will fail since it will look for the old > libfoo.x instead of libfoo.(x+1)). > > 5) Silent changes to the port distfile which have significant > functional differences, i.e. changes to the distfile requiring a > correction to distinfo with no corresponding change to PORTVERSION, > where a diff -ru of the old and new versions shows non-trivial changes > to the code. > > Soon, I think that item 2 told me to bump it. > Yes, you're right, PH says that, but personally I think that a PORTREVISION bump is not needed in this case. It's true that you have changed the install-time behaviour, but you don't need to make the users upgrade the port just because of the new pkg-message. As they have the port installed, we can suppose that they don't need those instructions now. Gábor
State Changed From-To: open->feedback Ask for maintainer approval.
lippe 2008-05-12 15:26:51 UTC FreeBSD ports repository Modified files: misc/pinfo Makefile Log: - Update MASTER_SITES. PR: ports/121884 Submitted by: Marcin Cieslak <saper@system.pl> Approved by: gabor (mentor) Revision Changes Path 1.36 +1 -1 ports/misc/pinfo/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
lippe 2008-05-12 15:29:42 UTC FreeBSD ports repository Modified files: mail/libpst Makefile Log: - Update MASTER_SITES. PR: ports/121884 Submitted by: Marcin Cieslak <saper@system.pl> Approved by: gabor (mentor), maintainer timeout (> 2 weeks) Revision Changes Path 1.5 +1 -1 ports/mail/libpst/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: feedback->closed Committed. Thanks!