Re: How to prevent locally compiled packages from upgrading

[adr <adr%sdf.org@localhost>]

On Sun, 18 May 2025, Ramiro Aceves wrote:

> Date: Sun, 18 May 2025 15:52:55 +0200
> From: Ramiro Aceves <ea1abz%gmail.com@localhost>
> To: PkgSrc Users Discussion List <pkgsrc-users%netbsd.org@localhost>,
>     Jonathan Perkin <jperkin%pkgsrc.org@localhost>
> Subject: Re: How to prevent locally compiled packages from upgrading
>
>
>
> El 18/5/25 a las 11:04, Jonathan Perkin escribió:
> >  * On 2025-05-18 at 08:01 BST, Ramiro Aceves wrote:
> >
> > >  Now pkgin upgrade wants to upgrade them. How can I hold them into the
> > >  current version without touching my locally compiled and installed ones?
> >
> >  The way to think of pkgin is that it is a program that syncs your chosen
> >  packages keyed on PKGPATH with whatever is available in its configured
> >  repository.  Regardless of whether the version in the repository goes
> >  forwards, backwards, or sideways, pkgin will sync it as long as it has the
> >  same PKGPATH.
> >
> >  So, if you build your own local versions of any particular programs, you
> >  need to make sure they have a different PKGPATH to those available in the
> >  repository.  Then pkgin will treat it as a completely different package.
> >
> >  One of the ways I've suggested folks do this in the past is to create a
> >  pkgsrc/local directory, and then symlink from there to the packages you
> >  maintain locally, so for example:
> >
> >     pkgsrc/local/gnuradio-core -> ../ham/gnuradio-core
> >
> >  then build via that symlink (assuming WRKOBJDIR is set to a non-symlink
> >  directory) and the package will have PKGPATH=local/gnuradio-core.
> >
> >  An alternative is to edit the +BUILD_INFO files for each package in
> >  question and change PKGPATH there directly, but this will need to be done
> >  every time you upgrade them.
> >
> >  This might be something I add more formally to pkgin at some point, but
> >  the problem is that pkgsrc is specifically designed to always be in sync
> >  with itself, and there's no way to officially support the notion of "do
> >  not touch this package" without immediately removing any guarantee that
> >  the package will continue to work in any capacity whatsoever.  Users
> >  should be fully aware that anything that diverges from an exact copy of
> >  what is available in the remote repository is highly likely to break.
> >
> >  Hope that helps,
>
> Hello Jonathan,
>
> Thanks very much for you great help. Sorry, I am very novice with this and I 
> think I have not  understood well the proposed procedure.
>
> I have just created a local directory inside the usual pkgsrc tree 
> /usr/pkgsrc/:
>
> /usr/pkgsrc/local
>
> I make a symbolic link:
>
> netbsd-x260# pwd
> /usr/pkgsrc/local
>
>
> netbsd-x260# ls -l
> total 0
> lrwxr-xr-x  1 root  wheel  20 May 18 15:22 gnuradio-core -> 
> ../ham/gnuradio-core
> netbsd-x260#
>
> netbsd-x260# cd gnuradio-core/
>
> netbsd-x260# make install
>
> ....
> ...
> .
>
>
>
>
> netbsd-x260# pkg_info -B gnuradio-core|grep PKGPATH
> PKGPATH=ham/gnuradio-core
>
>
>
> PKGPATH is the same as before.
>
>
> Thanks in advance.
> Ramiro.

Hi Ramiro, instead of complicating your life so much, why don't
you use the pkg_* utilities until your changes are cooked in the
next batch?

Unless you are using current pkgsrc, there is really not a big
need for updating before a quarter, isn't it? And if that is not
the case, you can use pkg_add to update just the packages you want.

On the other hand, as you are changing these packages yourself, why
don't you change the revision to a higher one, and pass the "<" flag
with the -l option to pkgin?

PS. I'm glad you got your radio equipment working on netbsd.

Regards.
adr