pkgsrc-Users archive

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

Re: mk.conf error from pkg_chk



Martin Husemann <martin%duskware.de@localhost> writes:

> On Wed, Jan 29, 2025 at 12:25:44AM +0100, Roland Illig wrote:
>> Once you have pkgsrc source and pkgsrc binary set up, chances are low
>> that one of them moves to a different location.
>
> I disagree. pkg_chk is a simple shell script and you can easily copy it
> over to a new (empty) machine's /tmp and have it install the binary
> pkgs you want (/tmp/pkg_chk -ab) from a binary pkg repo. It will then
> install the proper pkg_chk version too.

Copying a script from an installed package to another system is in my
view not an ok thing to do; I'd say that it leads to undefined behavior.

But, the binary package should be fine to use.

I run into problems with pkg_chk's hardcoding pretty often.   I have
package building domUs, and they have pkgsrc branches mounted as
/nfs/pkgsrc-2024Q4, from an nfs server with a zfs dataset with a
matching name.  I have a dir /links, with pkgsrc being a symlink to the
current quarterly branch, and move those links.

Then, pkg_chk, not otherwise rebuilt, fails.  Or maybe it's some other
similar tool, lintpkgsrc.

All in all, I don't see the location of sources as fundamental to a
pkgsrc installation.

For pkg_chk, lintpkgsrc, pkg_rolling-replace, I would be ok with an
expectation that you have to run them in the top level of your pkgsrc
directory, or rather the pkgsrc directory you wish them to operate on.


Home | Main Index | Thread Index | Old Index