tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Local patch revision in PKGREVISION



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
>>
>


Home | Main Index | Thread Index | Old Index