[Bug 232350] ports-mgmt/pkg: periodic pkg-checksum and pkg-backup interfere with 'overnight' port builds

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232350

--- Comment #21 from Bob Frazier <bobf at mrp3.com> ---
having entries in pkg.conf is useful, but can they be automatically
added/removed by the ports build system?  Having to manually fiddle with this
over-complicates the ports build process.

And, it seems to me that building/installing poudriere on an embedded device
(like Raspberry Pi) is probably not a good solution for simply building from
ports on the same device.  In my opinion, that "breaks ports".


If I had unlimited bandwidth, unlimited CPU, unlimited RAM, and unlimited disk
access speed/space, and unlimited time to read all of the documentation and get
familiar with how to set it up correctly, then certainly 'install poudriere'
would be a simple and adequate solution.  But for older and embedded hardware,
and generally busy people, not so much.  I'd rather just go to the ports
directory and type 'make install', thanks, and have the system work as
intended.


Another possibility I suggested earlier is for pkg to have "a file someplace",
in /var/run, in /tmp, doesn't really matter where all that much, but one that's
locked in a way that allows for simultaneous locking by other processes, and
prevents the periodic process from locking the entire pkg database.

non-exclusive locks seem to be one of the best ways to make this work, with an
exclusive lock on the same file from periodic processes.  It's a method I've
used before for concurrency of this kind.

In a makefile context it may be possible to start a daemon process that tracks
the PID of the parent process as part of the make environment.  When the parent
process stops (complete or error), the daemon would exit.  The daemon would
then keep the non-exclusive lock on the file.  If the 'pkg' utility were
modified to do the locking, it could be something like 'pkg --lock' to do a
non-exclusive lock (and run the daemon), and 'pkg --xlock' to do an exclusive
one, with this command being called for the appropriate context [the difference
would be for building 'pkg' itself, which would have to just work without doing
this step].  The 'pkg' utility would return an error code if the lock fails,
and whatever process would check for this and act appropriately.

-- 
You are receiving this mail because:
You are the assignee for the bug.