[geos-devel] 3.0.2

Paul Ramsey pramsey at cleverelephant.ca
Fri Oct 17 18:40:12 EDT 2008


What's the "10 second rule" for dropped releases? :)

P

On Fri, Oct 17, 2008 at 3:32 PM, Greg Troxel <gdt at ir.bbn.com> wrote:
>> Is this why some projects do RCs? ;)
>>
>> 3.0.1RC1, 3.0.1RC2, 3.0.1RC3?
>>
>> Or was Frank only suggesting this for the 3.1.0 level of release?
>>
>> Would these little issues happening in an RC-release cause less
>> problems for packagers? At least it would save us the "version creep"
>> (if we care).
>
> (Speaking as the pkgsrc maintainer for geos and postgis.)
>
> The issue is that once there is a foo-x.y.z.tar.gz out there (a
> 'distfile' in pkgsrc speak), and a packaging system references it, a
> checksum of the distfile is stored and the wrapper build scripts are
> tuned to that particular exact distfile.  Then mirror sites fetch the
> distfile and store it.  If the distfile changes, the checksum will not
> match.  To work around the file changing, in pkgsrc we assign
> DIST_SUBDIR to a new directory so that the old cached contents will be
> ignore.
>
> I don't have any problem with "version creep"; we have an infinite
> supply of even small integers.  I don't think it matters much if one
> uses an rcN suffix or just increments the numbers.
>
> In this case, it seems 3.0.2 has been regenerated with the right dir, so
> I'll just package that - because I didn't package the older 3.0.2 it
> doesn't matter.
>
>
> pkgsrc guide says:
>
>  19.2.2. How to handle modified distfiles with the 'old' name
>
>  Sometimes authors of a software package make some modifications after
>  the software was released, and they put up a new distfile without
>  changing the package's version number. If a package is already in
>  pkgsrc at that time, the checksum will no longer match. The contents
>  of the new distfile should be compared against the old one before
>  changing anything, to make sure the distfile was really updated on
>  purpose, and that no trojan horse or so crept in. Please mention that
>  the distfiles were compared and what was found in your commit
>  message. Then, the correct way to work around this is to set
>  DIST_SUBDIR to a unique directory name, usually based on
>  PKGNAME_NOREV. All DISTFILES and PATCHFILES for this package will be
>  put in that subdirectory of the local distfiles directory. (See
>  Section 19.1.11, "How to handle incrementing versions when fixing an
>  existing package" for more details.) In case this happens more often,
>  PKGNAME can be used (thus including the nbX suffix) or a date stamp
>  can be appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget
>  regenerating the distinfo file after that, since it contains the
>  DIST_SUBDIR path in the filenames. Also increase the PKGREVISION if
>  the installed package is different.  Furthermore, a mail to the
>  package's authors seems appropriate telling them that changing
>  distfiles after releases without changing the file names is not good
>  practice.
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>


More information about the geos-devel mailing list