tech-pkg archive

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

Re: Local patch revision in PKGREVISION



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