Subject: Re: CVS commit: pkgsrc/pkgtools/pkg_install/files
To: Jeroen Ruigrok/asmodai <firstname.lastname@example.org>
From: Jeremy C. Reed <email@example.com>
Date: 06/11/2005 21:07:50
On Sun, 12 Jun 2005, Jeroen Ruigrok/asmodai wrote:
> -On [20050611 20:22], Hubert Feyrer (firstname.lastname@example.org) wrote:
> >Because we can say the user who complained that version X doesn't
> >build: "get version Y, it will build".
> >I have repeatedly bumped the revision after committing fixes to a package
> >that make it built, e.g. from bulk build fallout or others, and it is my
> >gut feeling that we should continue to do so.
> Exactly. Arguing semantics over whatever feels historically right will mean
> jack to Joe Average User that just wants his stuff to work. And refering to
> a specific version of a tool to said user in order to answer his question
> why it does not work makes a lot of support people happy.
But in this specific case, it does not matter because there was not any
package in the first place for that version (because the package would not
We never say to any pkgsrc user to update to a certain "pkgsrc"
specification based on a package version. We mostly say update pkgsrc or
give the specific CVS revision numbers to update to.
Since this was a build bug that didn't change the outcome of packages
already building on other platforms, I consider this similar to making a
change in the build infrastructure in which we would rarely ever change
package versions for either.
Nevertheless, we always expect vendors who provide software that we
package to always update their version on their download source no matter
how trivial the change. This helps, of course, with our integrity
checksums (distinfo) but also helps us know what is what.
I am not sure what the best way is to keep track of a version for
Jeremy C. Reed
BSD News, BSD tutorials, BSD links