pkg lock/unlock needs flag to unlock temporarily all packages then relock same packages

[syleishere]

Feature Request Badly Needed:

Imagine following scenario in FreeBSD, time to upgrade 100 locked packages with custom options from ports collection: pkg unlock alpine; pkg unlock p5-DBD-mysql .... VERY LONG LINE (now we have to keep track of all these packages to lock them back) portmaster -adG (upgrade ports) pkg lock alpine; pkg lock p5-DBD-mysql .... VERY LONG LINE

I propose a flag to "pkg unlock" that temporarily allows upgrades to all locked packages, then a flag to "pkg lock" that locks them all back, this way we do not have to keep track of all packages to lock back. "pkg lock/unlock" currently puts a "yes" or "no" when viewing "pkg info -ak". I propose a third option of "wait", and anything with "wait" flag, set back to "yes", once "pkg lock +FLAG" run.

Dan.

[syleishere]

Example for Man Page: NEW FLAG unlock -w Unlocks all locked packages to a wait state to be relocked later with lock -w command NEW FLAG lock -w Locks all unlocked packages in wait state that were unlocked with -w flag

Code: unlock -w, (sets "pkg info -ak" to show "wait" instead of "yes" or "no" and "wait" code unlocks packages. lock -w (detects which packages have "wait" set, changes status to "yes" to relock them.)

End result: pkg unlock -w portmaster -adG pkg lock -w

much cleaner and easier.

[bdrewery]

Or an env override that portmaster/ports always sets.

Pkg lock is mostly intended for packages now. Portmaster has its own mechanism for this.

On Mar 13, 2014, at 5:37, syle notifications@github.com wrote:

Feature Request Badly Needed:

Imagine following scenario in FreeBSD, time to upgrade 100 locked packages with custom options from ports collection: pkg unlock alpine; pkg unlock p5-DBD-mysql .... VERY LONG LINE (now we have to keep track of all these packages to lock them back) portmaster -adG (upgrade ports) pkg lock alpine; pkg lock p5-DBD-mysql .... VERY LONG LINE

I propose a flag to "pkg unlock" that temporarily allows upgrades to all locked packages, then a flag to "pkg lock" that locks them all back, this way we do not have to keep track of all packages to lock back. "pkg lock/unlock" currently puts a "yes" or "no" when viewing "pkg info -ak". I propose a third option of "wait", and anything with "wait" flag, set back to "yes", once "pkg lock +FLAG" run.

Dan.

— Reply to this email directly or view it on GitHub.

[syleishere]

pkg lock/unlock need to be able to take multiple package names like "install" does as well.

[syleishere]

bdrewery:

The problem lies now that binary packages and ports packages are put into SQLite database with pkg. So lets say we do "pkg upgrade", that will attempt to install binary version upgrade over your ports, effectively loosing all your config options of the ports build. It only makes sense to first do a "pkg upgrade" , to upgrade binaries first as that takes the least amount of time. Then unlock locked packages for portmaster to upgrade ones from ports.

[syleishere]

Here is complete run down, of an example FreeBSD upgrade, first doing binaries then ports:

PORTS - UPGRADE

pkg version -v (see what ports out of date) pkg upgrade (upgrade binary ports first) locked (alias locked='pkg info -ak|grep yes')( check locked ports to unlock for portmaster and update list to unlock/lock below ) pkg unlock alpine; pkg unlock p5-DBD-mysql (ADD ANY PACKAGES MISSING HERE FROM "locked" COMMAND - unlock ports) portmaster -adG (upgrade ports) pkg lock alpine; pkg lock p5-DBD-mysql (ADD ANY PACKAGES MISSING HERE FROM "locked" COMMAND - lock ports back)

[syleishere]

I would like to say, I like new system. It was very much needed for FreeBSD. A lot of companies were bitching to upgrade 100 servers, they would prefer new system for quick upgrades. That being said, we do not want to take away from FreeBSD's most powerful feature over every other OS. Custom port config options for ports when needed. I mean what would be ideally the best is having anything installed from ports detected to only be upgraded from there. But in meantime locking packages seems to be only solution. Dependancies of ports are not needed as ports builds either in most cases.

The new system really adds to FreeBSD, allowing possibly commercial companies to now fully take advantage of private repositories to build on the OS with custom port option builds. FreeBSD really lacked in this area till now. It still needs more work on taking hypervisor market share as well, but in meantime, having ability to keep the power of FreeBSD ports, along with binary upgrades and remote repositories, really is a big step forward.

[Jamie-Landeg-Jones]

Whilst on the subject of locking, I was recently installing a friends system and his link was slow - one particular pkg install had 35mins remaining simply fetching the package.

Whilst waiting, I attempted to install some other packages, but couldn't, as the db was locked.

I haven't had a chance to look at the code yet, but surely a lock should happen after the fetch phase. Also, why does a lock cover the whole db and not just a port and its dependencies?

cheers

[vstakhov]

Pkg now has different locking system for a database and this issue is no longer relevant.

[infracaninophile]

On 13/03/2014 18:54, Vsevolod Stakhov wrote:

Pkg now has different locking system for a database and this issue is no longer relevant.

Err.. what?

The OP is not talking about the internal locking schemes in the DB, but pkg-lock(8).

Matthew

Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey

[vstakhov]

I replied to the last comment.

[syleishere]

http://blog.sunsaturn.com/freebsd/freebsd-10-ports-and-pkg2ng-how-to-deal-with-binaries-and-ports-collection-at-same-time/

[vstakhov]

Regarding to the original issue. pkg lock is a hack, that is ugly one and it should be removed anyway. The first step was a more clever solver. The second step will be implementing more clever repositories.

[bapt]

I 100% agree here :)

2014-03-14 15:53 GMT+01:00 Vsevolod Stakhov notifications@github.com:

Regarding to the original issue. pkg lock is a hack, that is ugly one and it should be removed anyway. The first step was a more clever solver. The second step will be implementing more clever repositories.

Reply to this email directly or view it on GitHubhttps://github.com/freebsd/pkg/issues/744#issuecomment-37655219 .

[syleishere]

Clever repositories? No one is going to compile a repository for every possible combination of makefile options. No one is going to want to spend the time to maintain that either. A solution for sys admins to just retain options they require on a case by case basis is much preferred.

[Jamie-Landeg-Jones]

Pkg now has different locking system for a database and this issue is no longer relevant.

Ahh, OK, thanks.

And sorry for confusing things by hijacking this thread

jamie

[infracaninophile]

On 14/03/2014 15:00, Baptiste Daroussin wrote:

I 100% agree here :)

2014-03-14 15:53 GMT+01:00 Vsevolod Stakhov notifications@github.com:

Regarding to the original issue. pkg lock is a hack, that is ugly one and it should be removed anyway. The first step was a more clever solver. The second step will be implementing more clever repositories.

Reply to this email directly or view it on GitHubhttps://github.com/freebsd/pkg/issues/744#issuecomment-37655219

Well, gee. Thank you all so much. It's so nice to feel appreciated.

Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey JID: matthew@infracaninophile.co.uk

[lhunath]

Is there any consensus on this issue? In the interim, I would recommend that it be made more explicit when pkg upgrade modifies the options of installed packages. This type of destructive action is currently invisible, which is really not acceptable.