Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Nov 2018 21:20:12 +0000
From:      bugzilla-noreply@freebsd.org
To:        pkg@FreeBSD.org
Subject:   [Bug 232350] ports-mgmt/pkg: periodic pkg-checksum and pkg-backup interfere with 'overnight' port builds
Message-ID:  <bug-232350-32340-iRQXnhr1Ld@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-232350-32340@https.bugs.freebsd.org/bugzilla/>
References:  <bug-232350-32340@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232350

--- Comment #21 from Bob Frazier <bobf@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 th=
is
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 d=
isk
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 hardwa=
re,
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 someplac=
e",
in /var/run, in /tmp, doesn't really matter where all that much, but one th=
at'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 tra=
cks
the PID of the parent process as part of the make environment.  When the pa=
rent
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 exclusi=
ve
one, with this command being called for the appropriate context [the differ=
ence
would be for building 'pkg' itself, which would have to just work without d=
oing
this step].  The 'pkg' utility would return an error code if the lock fails,
and whatever process would check for this and act appropriately.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-232350-32340-iRQXnhr1Ld>