[split] Perl upgrade, no updates for 1 year 250 days

[segmentation-fault]

In old day it was suggested do emerge @system before emerge @world

I didn't say it, but, for me, updating @system first and foremost is prerequisite no. 1. I will not continue with anything else before I am sure that the basic system is updated. This may not be required today (indeed I searched for it and did not find it mentioned as part of the update procedure in the Wiki, for example), but, given the situation we are discussing here (a system that has long gone without updates, with long meaning rather years than months), it is your safety net. Sync, update portage, update your toolchain (gcc, binutils, libtool), choose your gcc version, update @system, try updating @world (and fail at that last part) - that's how I do it. If I fail at some later point, at least I have a basic system up-to-date and working.

Hu's set technique (with @critical and @optional sets) is certainly worth a try - and could be part of a solution. Quite a lot of investment needed though, at least at the start, to define those sets...

[NeddySeagoon]

segmentation-fault,

- Update Perl, but Perl and its modules ONLY - don't care about programs with the 'perl' flag, for example.
- Update Lua ONLY - spare me the hassle to go through Qt, or anything else, just because some Qt program has the 'lua' USE flag set.
- Update icu ONLY.

What you don't say there is that you want your system to work despite the fact that you don't mind what breaks and you expect the package manger to pick up the pieces (if it still works) after you have told the tools/package manager to break things.

Your stated requirements and unstated assumptions are contradictory.

It's rather like the Power on Self Test when you switch your PC one.
When its broken and not operating correctly, you expect it to correctly tell you that its broken and even tell you where.

[pingtoo]

Hi segmentation-fault,

Here we talked a lot of con for today's portage/emerge and many of your points I am totally agree and wish just like you to have something that will do that. However I feel that there is no need to create yet another set of tools or create even more complicated emerge options.

I believe current emerge with all its options plus gentoolkit or equery can already do what you asking.

The only problem is better document and/or example. I do find many emerge option document not able to explain very will what exactly it will achieve. for example when emerge with --usepkg at the end before actually perform the install, it will prompt a message suggest choice additional two options "--binpkg-respect-use [ y | n ]" or "--binpkg-changed-deps [ y | n ]" just taking the option name and try to guess what exactly will be install on my machine is frustrating.

I think part of unpleasantness you experience is due to emerge present it self as run once solve all program. but off cause it is actually not. I mean if you start off assume your 500+days old system need a multiple incremental steps you may found emerge actually very capable do what you want.

I personal interesting in expert system, I have imaging the emerge process is very good case for using expert system to solve. However when I learn more about expert system more I realize that end expert system may be ever more frustrate for user. Because when a blocking condition (not in emerge sense, but expert system rule sense) a prompt need to present to user ask select one of few possible options to solve the blockade, hopefully in the prompt can explain each option outcome. Once a option chosen and go back to re-calculate and possible come to yet another blockade which require interaction. This unlikely be very useful.

So overall, if you plan to infrequent update I suggest you clone portage tree and plan for a multiple step incremental update. I found this way will greatly reduce stress.

[segmentation-fault]

What you don't say there is that you want your system to work despite the fact that you don't mind what breaks

Well, it's not that bad as your depict it. Of course, I will not tell it "go break Python and tell me how it goes". But, as you can read in my notes at the very start, I would appreciate a way to tell it "upgrade Perl, but don't bother about programs that have the 'perl' USE flag set (e.g. postgresql)", for example. That would not break anything vital for me, but would upgrade at once 500 of my 4000 installed packages - a big deal. I would love to have the option to exclude packages with a given USE flag (or flags) from merging. I would also not complain if I would hose my system that way.

We do allow

Code: Select all

rm -rf /

for root, don't we? So what? I know what I'm doing. [1]

[1] Well, most of the time - one night, a long time ago, I was sleepy and typed exactly that, as root. Did I come here to complain?

[NeddySeagoon]

segmentation-fault,

Its not as simple as not caring about things that have USE=perl set.
What about all the things that hard depend on perl like

Code: Select all

app-admin/perl-cleaner-2.30 (dev-lang/perl)
app-admin/sudo-1.9.8_p2 (ldap ? dev-lang/perl)
app-crypt/mhash-0.9.9.9-r2 (dev-lang/perl)
app-doc/doxygen-1.9.3 (dev-lang/perl)
app-emulation/libvirt-7.10.0-r2 (dev-lang/perl)
app-emulation/qemu-6.2.0-r2 (dev-lang/perl)
app-office/libreoffice-7.2.5.2 (dev-lang/perl)
app-portage/genlop-0.30.10-r2 (dev-lang/perl)
app-portage/ufed-0.96 (dev-lang/perl)
app-text/App-XML-DocBook-Builder-0.100.300-r1 (dev-lang/perl)
                                              (dev-lang/perl)
app-text/docbook2X-0.8.8-r4 (dev-lang/perl)
app-text/po4a-0.65 (dev-lang/perl)
                   (dev-lang/perl)
app-text/qpdf-10.5.0 (dev-lang/perl)
cross-aarch64-unknown-linux-gnu/linux-headers-5.16 (dev-lang/perl)
cross-alpha-unknown-linux-gnu/linux-headers-5.13 (dev-lang/perl)
cross-mips64el-unknown-linux-gnu/linux-headers-5.16 (dev-lang/perl)
dev-lang/nasm-2.15.05 (dev-lang/perl)
dev-libs/hyphen-2.8.8-r1 (dev-lang/perl)
dev-libs/libcdio-2.1.0-r1 (test ? dev-lang/perl)
dev-libs/libcdio-paranoia-2.0.1 (test ? dev-lang/perl)
dev-libs/libical-3.0.12 (dev-lang/perl)
dev-libs/nss-3.74 (dev-lang/perl)
dev-libs/openssl-1.1.1m (>=dev-lang/perl-5)
...
net-misc/curl-7.80.0 (dev-lang/perl)
net-misc/wget-1.21.2 (dev-lang/perl)
...

You are OK with not being able to fetch any more source code because wget and curl are broken?
KDE users would be very upset. as lots of Qt packages appear in

Code: Select all

equery d perl | grep -v virtual

too.
So, yes, it is that bad, you just don't know it yet.

[pingtoo]

I would appreciate a way to tell it "upgrade Perl, but don't bother about programs that have the 'perl' USE flag set (e.g. postgresql)", for example

May be you can try

Code: Select all

emerge ... --exclude $(quse --installed --quiet --nocolor perl)

That would not break anything vital for me

I don't think there is a tool in gentoo will able automatically determine what is vital for you

[segmentation-fault]

I would appreciate a way to tell it "upgrade Perl, but don't bother about programs that have the 'perl' USE flag set (e.g. postgresql)", for example

May be you can try

Code: Select all

emerge ... --exclude $(quse --installed --quiet --nocolor perl)

Ah...what a wonderful command! If only I knew quse before! Yes, you are right, this could be what I need! I didn't test it in a real-world scenario yet, but looks like exactly what I was missing when I was trying to upgrade Perl. Let's see:

Code: Select all

quse --installed --quiet --nocolor perl

app-editors/gvim
app-editors/vim
app-office/gnumeric
app-text/qpdf
app-text/sablotron
app-text/stardict
dev-db/mysql
dev-db/postgresql
dev-db/postgresql
dev-db/postgresql
dev-db/postgresql
dev-db/qdbm
dev-lang/R
dev-libs/lockdev
dev-util/strace
dev-vcs/git
dev-vcs/subversion
media-gfx/graphicsmagick
media-gfx/graphite2
media-gfx/graphviz
media-gfx/imagemagick
media-sound/xmms2
net-analyzer/nagios-core
net-analyzer/net-snmp
net-analyzer/rrdtool
net-nds/openldap
net-print/cups-filters
net-proxy/squid
sci-libs/gdal
sys-apps/i2c-tools
sys-apps/xinetd
sys-libs/libapparmor
virtual/imagemagick-tools
www-servers/nginx
www-servers/nginx-unit
x11-wm/fvwm

The various dev-db/postgresql entries are from the various slots dev-db/postgresql occupies. So you might need to pipe this through sort and uniq, but that's OK.

@NeddySeagoon, as you can see from the above list, doing

Code: Select all

emerge -1av dev-lang/perl --exclude $(quse --installed --quiet --nocolor perl | sort | uniq)

would exclude the above packages - but nothing like the packages you mention. This is because you consider the packages that hard depend on Perl (the language), while I wanted to exclude those that USE depend on 'perl' (the USE flag). You are right, I would get into more trouble if I had done

Code: Select all

emerge -1av dev-lang/perl --exclude-world

which would have the effect of (also) excluding the packages that hard depend on Perl.

By now I am quite confident that a judicious use of --exclude world and --exclude $(quse --installed ...) can resolve situations like mine. Maybe these techniques should be more prominently used. I mean, instead of repeating the mantra of update, update, update, one could also say "don't worry, even if you didn't update for two years, we have

• --exclude world
  --exclude $(quse --installed ...)
  a technique with @critical and @optional sets

for you to use carefully and help you out". Yes, this list looks good. With a detailed explanation and examples in the Wiki, I can imagine that it could make Gentoo fun again!

[segmentation-fault]

NeddySeagoon,

in addition to the above, there is another point that reinforces my position:

I examined wget that, according to you, would break if I excluded it from the Perl upgrade. I just could not believe that wget really depends hard on Perl, so I looked at the ebuild /usr/portage/net-misc/wget/wget-1.21.2.ebuild (I have made it a habit to look into the ebuilds for such things, because all-too-often the situation is not what tools like qdepends suggest at first glance):

The dependencies of wget are built through

Code: Select all

LIB_DEPEND="
    cookie-check? ( net-libs/libpsl )
    idn? ( >=net-dns/libidn2-0.14:=[static-libs(+)] )
    metalink? ( media-libs/libmetalink )
    pcre? ( dev-libs/libpcre2[static-libs(+)] )
    ssl? (
        gnutls? ( net-libs/gnutls:0=[static-libs(+)] )
        !gnutls? ( dev-libs/openssl:0=[static-libs(+)] )
    )
    uuid? ( sys-apps/util-linux[static-libs(+)] )
    zlib? ( sys-libs/zlib[static-libs(+)] )
"
RDEPEND="!static? ( ${LIB_DEPEND//\[static-libs(+)]} )"
DEPEND="
    ${RDEPEND}
    static? ( ${LIB_DEPEND} )
"
BDEPEND="
    app-arch/xz-utils
    dev-lang/perl
    sys-apps/texinfo
    virtual/pkgconfig
    nls? ( sys-devel/gettext )
    test? (
        ${PYTHON_DEPS}
        dev-perl/HTTP-Daemon
        dev-perl/HTTP-Message
        dev-perl/IO-Socket-SSL
    )
"

Perl appears as a build dependency (i.e. it is needed only to build wget, in case one decided to upgrade it) and, looking at BDEPEND, I would say it is needed during build probably only for testing, although not sure. But even if wget would absolutely require dev-lang/perl to build, that's not a problem for an already installed wget. So it's safe to exclude it from a Perl upgrade.