I think having such a facility would be great, a number of use cases
exist for it.
Ordering would be lower than PKGREVISION; the lowest, in fact.
However, one thing to consider also that, occasionally, local mods
should be persistent across upstream version bumps. And that, along
with having centralised directory for local patches, a way of keeping
updated version numbering in a central place and not in pkgsrc
Makefiles would also be super-useful.
IIRC, the dewey numbering assumes the "nb" suffix to be a simple
integer, and considered after everything else, so "nb7p1" would not
work. Any local modifier (any objections to using "local" apart from
the begin/ending "l"s being confused for "1"s, and LOCALREVISION for
the variable name?) would have to be coded as such, but it's not that
much work.
On 14 July 2017 at 07:30, Tim Zingelman <tez%netbsd.org@localhost> wrote:
My most common use case is backporting a security fix when pkgsrc has long
since moved on to a newer version. I do this when said newer version would
require a bunch of other updates that I can't make on stable production
systems. I only get to do a 'fresh' set of packages about once every 18
months... otherwise it is security fixes only. For this use case I
currently just bump PKGREVISION since I know there will not be an accidental
match with a real pkgsrc version. - Tim
On Fri, Jul 14, 2017 at 9:11 AM, Stephen Borrill <netbsd%precedence.co.uk@localhost>
wrote:
On Fri, 14 Jul 2017, D'Arcy Cain wrote:
On 07/14/2017 05:07 AM, Stephen Borrill wrote:
On Thu, 13 Jul 2017, D'Arcy Cain wrote:
If it's strictly local why bother? Just "make replace" or remove the
package before rebuilding. PKGREVISION is meant for causing rebuilds when
the user doesn't realize that a change has been made e.g. when running
pkg_rolling-replace.
By local I mean not committed to pkgsrc. The built packages are used by
customers' machines, so the change needs to be noticed by them.
Yes, I understood that. And now I understand the child server
requirement. I just wonder if making local mods in a CVS tree as a matter of
course is the cleanest method. Of course I don't know your actual situation
so I can't really say. From this discussion it sounds like you regularly
need to modify packages after they have been installed elsewhere and that it
happens often enough (or you have too many child servers) to be able to
handle each change manually.
What kind of modifications are you making that don't warrant an update to
pkgsrc itself?
It could just be changing the options the package was built with.
--
Stephen