[solved] rebuild packages without "linux" flag?

[freifunk_connewitz]

Hi,
Today's update (emerge -avuDU world) wanted to rebuild several packages, including baselayout, portage or cryptsetup, only due to a change in the "KERNEL" flag:

Code: Select all

[ebuild   R    ] sys-apps/portage-3.0.28-r1::gentoo  USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" KERNEL="(-linux%*)" PYTHON_TARGETS="python3_9 (-pypy3) -python3_8 -python3_10" 0 KiB

Which, IIRC, means, that the linux flag has been removed.

1. Why?
2. Is it safe to do so even if the box DOES run on a Linux kernel? I do not want to end up in a broken system (and I kind of lost full trust in portage after last time it removed xorg-server and left me without a working GUI).

Thank you.

Best,
FFC

[grknight]

This is just a clean up effort: https://archives.gentoo.org/gentoo-dev/ ... 2e71f1be87

It will not break anything.

[asturm]

But also pointless to do such rebuilds.

[Jaglover]

Yes, when using -U, not -N these rebuilds should not happen.

[freifunk_connewitz]

Yes, when using -U, not -N these rebuilds should not happen.

I did so, and they did occur.

Thank you for leading me to the clean up info. And regarding "pointless": yes, but not easy to avoid for users.

Solved

[asturm]

And regarding "pointless": yes, but not easy to avoid for users.

...there is nothing to avoid here since -N is something you request individually and then should better understand what it does in the first place.

[grknight]

Yes, when using -U, not -N these rebuilds should not happen.

Even when -U is used, it will happen because the state is changing from on (forced) to off and removed.

[jok]

Yes, when using -U, not -N these rebuilds should not happen.

Even when -U is used, it will happen because the state is changing from on (forced) to off and removed.

Thank you. I was trying to figure out why I was suddenly looking at >12 hours of rebuilds on an up-to-date system.

[freifunk_connewitz]

Yes, when using -U, not -N these rebuilds should not happen.

Even when -U is used, it will happen because the state is changing from on (forced) to off and removed.

And using -U is what I did (see OP). I normally do not use -N, as recommended.

[Ionen]

Unfortunately there's not much avoiding these this time around (given changed state going from enabled to removed which both -U and -N pick up), and stopping using -U wouldn't be something I recommend unless in a hurry (could run at night or so).

Perhaps some measures could've been taken to mitigate amount of rebuilds (e.g. remove on bumps, or for eclasses a very long term plan on EAPI bumps), although that's harder and longer to coordinate.. think it'd be a bit unrealistic over a few unnecessary rebuilds.

From my developer point of view, I'm happy to see this old cruft being removed anyhow -- although I get the impact for users is not great

[smartding]

A couple of packages require rebuild when I sudo emerge -auUD @world today:

Code: Select all

Calculating dependencies... done!
[ebuild   R    ] sys-apps/baselayout-2.7-r3  KERNEL="(-linux%*)"
[ebuild   R    ] app-misc/pax-utils-1.3.3  KERNEL="(-linux%*)"
[ebuild   R    ] dev-libs/ell-0.46  KERNEL="(-linux%*)"
[ebuild   R    ] sys-firmware/intel-microcode-20210608_p20210830  KERNEL="(-linux%*)"
[ebuild   R    ] sys-fs/udev-249.6-r2  KERNEL="(-linux%*)"
[ebuild   R    ] app-arch/libarchive-3.5.2  KERNEL="(-linux%*)"
[ebuild   R    ] net-misc/dhcpcd-9.4.0-r1  KERNEL="(-linux%*)"
[ebuild   R    ] virtual/service-manager-1  KERNEL="(-linux%*)"
[ebuild   R    ] sys-apps/lm-sensors-3.6.0  KERNEL="(-linux%*)"
[ebuild   R    ] sys-process/htop-3.0.5-r2  KERNEL="(-linux%*)"
[ebuild   R    ] dev-libs/rasqal-0.9.33  KERNEL="(-linux%*)"
[ebuild   R    ] dev-libs/glib-2.68.4  KERNEL="(-linux%*)"
[ebuild   R    ] dev-qt/qtcore-5.15.2-r11  KERNEL="(-linux%*)"
[ebuild   R    ] sys-auth/elogind-246.10-r1  KERNEL="(-linux%*)"
[ebuild   R    ] sys-apps/dbus-1.12.20-r4  KERNEL="(-linux%*)"
[ebuild   R    ] net-wireless/iwd-1.20  KERNEL="(-linux%*)"
[ebuild   R    ] net-misc/openssh-8.8_p1-r4  KERNEL="(-linux%*)"
[ebuild   R    ] net-print/cups-2.3.3_p2-r3  KERNEL="(-linux%*)"
[ebuild   R    ] media-libs/mesa-21.2.6  KERNEL="(-linux%*)"
[ebuild   R    ] x11-drivers/xf86-input-libinput-1.2.0  KERNEL="(-linux%*)"
[ebuild   R    ] x11-drivers/nvidia-drivers-470.94  KERNEL="(-linux%*)"
[ebuild   R    ] www-client/google-chrome-96.0.4664.110  KERNEL="(-linux%*)"
[ebuild   R    ] sys-apps/portage-3.0.28-r1  KERNEL="(-linux%*)"
[ebuild   R    ] app-portage/layman-2.4.3  KERNEL="(-linux%*)"

Looks like they all inherit the linux-info eclass, and there's a change of the eclass a few hours ago:

https://github.com/gentoo/gentoo/commit ... 1e86054e53

In that commit, the USE flag kernel_linux is considered unnecessary and dropped.

Should I rebuild these packages? Or should I re-enable this USE flag because I'm actually using linux kernel.

[grknight]

Previously discussed same day in [solved] rebuild packages without "linux" flag?

[smartding]

Previously discussed same day in [solved] rebuild packages without "linux" flag?

Thanks for pointing that out.

[Oleksa75]

Hello there!
Please can someone explain (or provide link to docs) next changes?

I noticed in latest update that most of packages must be re-build and came with new flag: KERNEL="(-linux%*)"
Please, explain what does it means?

Thanks!

[NeddySeagoon]

Oleksa75,

It means that nothing has changed. :)

Once upon a time, the KERNEL flag could be set to linux or bsd. BSD support was dropped several years ago.
Now the KERNEL flag is being removed as redundant, as it only had a single value anyway.

The installed binary code will not change.

[proteusx]

Besides KERNEL="-linux%", there are also ELIBC="-Free_BSD%" and USERLAND="-GNU% -BSD%" causing needless rebuilding.

It seems to me that someone has nothing better to do than to tinker with portage just to annoy me.

Not everyone has a 64 core Ryzen with 1TB of RAM, you know.

[Etal]

Besides KERNEL="-linux%", there are also ELIBC="-Free_BSD%" and USERLAND="-GNU% -BSD%" causing needless rebuilding.

It seems to me that someone has nothing better to do than to tinker with portage just to annoy me.

Not everyone has a 64 core Ryzen with 1TB of RAM, you know.

Then don't use -N/-U. It's that simple, really.

[proteusx]

Then don't use -N/-U. It's that simple, really.

That is beside the point.

In Gentoo one can do whatever one likes; so besides your suggestion, one has other options to circumvent such irksome and needless changes.

One can stop syncing all together. Syncing lately, more often than not, brings grief.

Also, one can patch portage/{profiles, eclass} to revert them to the state before the "developer" started the tinkering.

To prevent the needless rebuilding of some heavy stuff, like libreoffice and rstudio, I added this to /etc/portage/profile/package.use.mask

Code: Select all

*/* elibc_FreeBSD

So that I can continue with emerge -DuNa world as I have been doing since 2003.

[sam_]

Then don't use -N/-U. It's that simple, really.

That is beside the point.

In Gentoo one can do whatever one likes; so besides your suggestion, one has other options to circumvent such irksome and needless changes.

One can stop syncing all together. Syncing lately, more often than not, brings grief.

Also, one can patch portage/{profiles, eclass} to revert them to the state before the "developer" started the tinkering.

To prevent the needless rebuilding of some heavy stuff, like libreoffice and rstudio, I added this to /etc/portage/profile/package.use.mask

Code: Select all

*/* elibc_FreeBSD

So that I can continue with emerge -DuNa world as I have been doing since 2003.

You should actually just patch/modify /var/db/pkg if you wish rather than modifying the eclasses and such. And I'm sorry you feel the need to all us "developers" - the cleanup was long overdue.

Sometimes churn happens and it's often not really something we can control or prevent.

[proteusx]

You should actually just patch/modify /var/db/pkg

Yes. One could do this:

Code: Select all

find /var/db/pkg -type f -name "IUSE" -exec sed -i 's/elibc_FreeBSD//g' {} \;

Like I posted here and here when I needed to circumvent similar nonsense rebuilds.
This time around, masking the flag seemed to be the easiest option.

[figueroa]

You should run into notably fewer useless rebuilds for USE flag changes if you use -U instead of -N.

[krumpf]

Thanks to this thread, I now understand the why about so many rebuilds.
But imo, devs should/could have pushed a news item to explain all that to puzzled users like me

[proteusx]

The recent crops of developers ought to heed the age old maxim: If it ain't broke, don't fix it.
Tidying up the code should be of lower priority than not pissing off the users.

[pietinger]

If it ain't broke, don't fix it.

This is true but on the other side, reducing complexity has its benfits also: Less problems and higher security. I have learned: If something isnt used throw it away.

Tidying up the code should be of lower priority than not pissing off the users.

I understand your frustration, but when I look to the choices I see only these:

1. Change it in a way it was done
2. Never delete it
3. Changing it selectively for every package only when an update for this package occurs
4. Manipulate the database

My thinkings about:

1. We have a rolling distribution. Everyone using Gentoo knows this and is able to run an "emerge -uUDv @world" in the NIGHT (I do this always)
2. See what I have learned.
3. Maybe this would trigger the least drawback for users, but it comes with a tremendous monitoring investment.
4. This would also trigger the least drawback for users, but maybe could lead to problems you never have seen before.

I am not a developer and cannot tell why 3. and 4. wasnt used, but I believe there is a good reason. If I had to decide, I would always choose the most safety of them ... and I believe this is 1. (Maybe I am wrong here; it is only my view)

[figueroa]

The recent crops of developers ought to heed the age old maxim: If it ain't broke, don't fix it.
Tidying up the code should be of lower priority than not pissing off the users.

Fall on your face and thank the Gentoo developer community for all they do for us. A news item would have been nice, but a quick look in the forums told me all that I needed to know.