pkgsrc-Users archive

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

Re: mk.conf error from pkg_chk



On Wed, 29 Jan 2025 at 11:50, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> 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.

As a general rule, absolutely, though pkg_chk was intended for this to
be an option.
However it was never documented as such (an omission on my part).

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

Do you have anything in mk.conf directing to the current directory or symlink?
If you have, and pkg_chk is getting it wrong, that would definitely be a bug.
(lintpkgsrc has a different mechanism, so is likely to have different behaviour)

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

That would cause issues with at least some of my use cases. On all my
systems mk.conf defines where pkgsrc lives, and pkg_chk can Just Work
based on that.
If I had to change to the pkgsrc directory before running pkg_chk then
I would need to manually review mk.conf to determine where that may
be, and then cd there before running.

pkg_chk has a command line option to override the PACKAGES dir (and
can of course have MAKECONF, PKGSRCDIR, PACKAGES and similar set in
the environment), but I wonder if it might be helpful to have a
specific command line option to set PKGSRCDIR for cases like yours?

Thanks

David


Home | Main Index | Thread Index | Old Index