[gentoo-dev] pkg_rm_pretend?

[gentoo-dev] pkg_rm_pretend?

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

TL;DR: It would be very nice if when I did:

  emerge --depclean -va 

That important packages like say, Postgres could go "hey, that's ...
probably gonna break things, you haven't migrated, are you sure?"

Seeing notices *after* removing postgres that my system is now broken is not too inspiring.

In part, because you *CANT* perform a postgres migration after you remove the old version:

1. You can't stop the old service, because the init script is gone.
2. pg_upgrade doesn't work, because there's no binaries in the path passed to '-b' , as per:

https://wiki.gentoo.org/wiki/PostgreSQL/QuickStart#Migrating_PostgreSQL

This is especially annoying as:

1. Its very easy to overlook one package in a 400 package depclean notice. ...
2. Its not that postgres is no longer in world, but it got upgraded,
and you all know what that means when *slots* are involved.

Now imagine where I'd be if the version of postgres I just removed, I
had no way of reinstalling.

Related:

It would also be nice if pkg_pretend ( or something like it ) happened *BEFORE* offering the [Y/N]
prompt with `emerge -va `, not, as it currently does, wait until after
you press "y" to execute those checks.

Being able to generate notices, but not producing them until after you approve emerge is just daft.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] pkg_rm_pretend?

[Michael Orlitzky]

On 10/11/2017 12:20 PM, Kent Fredric wrote:
> TL;DR: It would be very nice if when I did:
> 
>   emerge --depclean -va 
> 
> That important packages like say, Postgres could go "hey, that's ...
> probably gonna break things, you haven't migrated, are you sure?"
> 

This might also scratch the itch I had[0] when I asked about "die" in
pkg_prerm -- namely, a way to make package removal fail under certain
conditions.


[0]
https://archives.gentoo.org/gentoo-dev/message/9c764b39e47b79290bcbf967fe5f0b38

[gentoo-dev] Re: pkg_rm_pretend?

[Duncan]

Kent Fredric posted on Thu, 12 Oct 2017 05:20:24 +1300 as excerpted:

> This is especially annoying as:
> 
> 1. Its very easy to overlook one package in a 400 package depclean
> notice.

Wow.  How'd you ever get a backlog of 400 packages in your depclean list, 
including critical ones you know you want to keep?   These days portage 
even strongly suggests running depclean after an --update @world, in part 
to avoid such huge and confusing backlogs when it is run.

> Related:
> 
> It would also be nice if pkg_pretend ( or something like it ) happened
> *BEFORE* offering the [Y/N] prompt with `emerge -va `, not, as it
> currently does, wait until after you press "y" to execute those checks.

That has irritated me a few times as well, tho I know /why/ it works that 
way.

As the name suggests, pkg_pretend is /supposed/ to be run at pretend 
time, thus before the --ask prompt, both as originally designed and as 
speced by PMS.  The problem the portage implementors apparently ran into 
is that some of the pkg_pretend stuff ends up being a bit expensive to 
run just to get the initial listing, so the (controversial) decision was 
made to run it /after/ the go-ahead.  If it's going to double the 
processing time just for a pretend...

Which kind of defeats the purpose I think, but...

Maybe what we need is a two-stage pretend/ask, a first stage that does 
the minimum dependency graphing, etc, and a second stage that does the 
pkg_pretend.

Then an --expensive flag could be added to enhance --pretend and --ask, 
that would run the second stage too, before the prompt for --ask.  Maybe 
--expensive could automatically double backtrack count as well, so people 
could run with a lower backtrack by default and choose whether to run
--expensive or deal with it manually if the lower backtrack didn't 
propose a satisfactory solution.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: pkg_rm_pretend?

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

On Thu, 12 Oct 2017 07:50:38 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Wow.  How'd you ever get a backlog of 400 packages in your depclean list, 
> including critical ones you know you want to keep?   These days portage 
> even strongly suggests running depclean after an --update @world, in part 
> to avoid such huge and confusing backlogs when it is run.

I maintain perl ... so ... that can happen within a week *easily*,
depending what I test-install. :)

On my chroot, I had a 1900 package depclean the other day that took 2
hours to run.

And yes, this was actually due to me going "oh, right, this box is
going to need to upgrade Perl soon, I should depclean *before* I sync
to make my life easier".

Welp.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-dev] Re: pkg_rm_pretend?

[Duncan]

Kent Fredric posted on Sun, 15 Oct 2017 06:36:34 +1300 as excerpted:

> On Thu, 12 Oct 2017 07:50:38 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Wow.  How'd you ever get a backlog of 400 packages in your depclean
>> list,
>> including critical ones you know you want to keep?   These days portage
>> even strongly suggests running depclean after an --update @world, in
>> part to avoid such huge and confusing backlogs when it is run.
> 
> I maintain perl ... so ... that can happen within a week *easily*,
> depending what I test-install. :)
> 
> On my chroot, I had a 1900 package depclean the other day that took 2
> hours to run.
> 
> And yes, this was actually due to me going "oh, right, this box is going
> to need to upgrade Perl soon, I should depclean *before* I sync to make
> my life easier".
> 
> Welp.

Perl maintainer... after seeing the number of new packages, often 2X due 
to virtuals as well, that the recent perl upgrade brought me...

Understood, now. =8^0

Tho a 1900-package-depclean... let's just say I'm glad you're doing it, 
not me, because I'm not sure /what/ I'd do with that, only that I'd 
probably not want to /touch/ anything sysadmin related for probably a 
month, after that!

I can also imagine doing something drastic like hourly depcleans, if 
that's what it too, too, after dealing with a 1900-pkg-depclean!  Yikes!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: pkg_rm_pretend?

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

On Sun, 15 Oct 2017 04:17:49 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> I can also imagine doing something drastic like hourly depcleans, if 
> that's what it too, too, after dealing with a 1900-pkg-depclean!  Yikes!

It does sound like a lot, but when you have minimal chroots with only 9
entries in world, something like say, khtml gets bumped, and I test it
because this line brings it to my attention: 

https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-frameworks/khtml/khtml-5.39.0.ebuild#n56

That's easily 300 odd new deps.

Only to be cleaned maybe hours later so I can ensure my tests don't
fail due to missing deps.

Admittedly, half this stuff I probably don't *need* to test, I
sometimes re-test things just because somebody keyworded/stabilized a
package ... but my "Has changed" and "is perl" =-> "something broken?
Test me maybe?!" tools are pretty senseless in this regard.

Besides, a broad brush is better anyway.

And as long as I don't slack off for too many days, that backlog is
pretty manageable.

Not even doing reverse-dep testing, that's ... uh. Yeah, I'll let
toralf handle that, I'll just make sure the latest perl versions aren't
breaking things for now.

Sometime soon I'm hoping to move on to testing against development
releases of Perl again.

But eh, mountain.shovel while true;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]