This is not about finding solution to upgrade the system (in this case
it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
about raising awareness that Gentoo is a rolling distribution and that
we guarantee users to be able to upgrade their system when they do world upgrades just once a year (remember: in my case the last world upgrade
is just 4 months old!). If they cannot upgrade their system without
manual intervention, we failed to do our job.
On Wed, 03 Nov 2021, Rich Freeman wrote:
On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
This is not about finding solution to upgrade the system (in this case
it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
about raising awareness that Gentoo is a rolling distribution and that
we guarantee users to be able to upgrade their system when they do world
upgrades just once a year (remember: in my case the last world upgrade
is just 4 months old!). If they cannot upgrade their system without
manual intervention, we failed to do our job.
Do we have this "guarantee" documented somewhere? I thought I've
heard six months tossed around. You say one year. It seems
reasonable to have some sort of guideline like this and try to stick
with it, at least for @system.
On Wed, 03 Nov 2021, Rich Freeman wrote:
On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
This is not about finding solution to upgrade the system (in this case
it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
about raising awareness that Gentoo is a rolling distribution and that
we guarantee users to be able to upgrade their system when they do world >> upgrades just once a year (remember: in my case the last world upgrade
is just 4 months old!). If they cannot upgrade their system without
manual intervention, we failed to do our job.
Do we have this "guarantee" documented somewhere? I thought I've
heard six months tossed around. You say one year. It seems
reasonable to have some sort of guideline like this and try to stick
with it, at least for @system.
We do. Summary of 2009-11-09 Council meeting:
| https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
|
| Upgrade path for old systems
| ----------------------------
| Vote (unanimous): The ebuild tree must provide an upgrade path to a
| stable system that hasn't been updated for one year.
| Action: leio will start a discussion on gentoo-dev on if and how to
| support upgrading systems that are outdated more than a year.
On 2021-11-03 17:44, John Helmert III wrote:
| Upgrade path for old systemsDoes "upgrade path" imply a simple world upgrade is all that should be necessary to upgrade the system? I wouldn't interpret it this way.
| ----------------------------
| Vote (unanimous): The ebuild tree must provide an upgrade path to a
| stable system that hasn't been updated for one year.
Could you please share your interpretation? I wonder how you can agree
on an upgrade path but still require manually hacking to get a system up-to-date. That is basically the definition of "upgrade path"...
On Wed, 03 Nov 2021, John Helmert wrote:
| https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
|
| Upgrade path for old systems
| ----------------------------
| Vote (unanimous): The ebuild tree must provide an upgrade path to a
| stable system that hasn't been updated for one year.
Does "upgrade path" imply a simple world upgrade is all that should be necessary to upgrade the system? I wouldn't interpret it this way.
An "upgrade path" to me sounds like not just a world update,
but also includes other stuff
that might be necessary to get a system fully updated,
like temporarily setting PYTHON_TARGETS to upgrade a package.
A system without an upgrade path would seem to be a system
where there is no way to upgrade it without reinstalling,
which you seem to be asserting is the case for this system.
On Wed, 03 Nov 2021, Rich Freeman wrote:
On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
This is not about finding solution to upgrade the system (in this case
it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
about raising awareness that Gentoo is a rolling distribution and that
we guarantee users to be able to upgrade their system when they do world >> upgrades just once a year (remember: in my case the last world upgrade
is just 4 months old!). If they cannot upgrade their system without
manual intervention, we failed to do our job.
Do we have this "guarantee" documented somewhere? I thought I've
heard six months tossed around. You say one year. It seems
reasonable to have some sort of guideline like this and try to stick
with it, at least for @system.
We do. Summary of 2009-11-09 Council meeting:
| https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
|
| Upgrade path for old systems
| ----------------------------
| Vote (unanimous): The ebuild tree must provide an upgrade path to a
| stable system that hasn't been updated for one year.
|
| Action: leio will start a discussion on gentoo-dev on if and how to
| support upgrading systems that are outdated more than a year.
Hi,
it is currently not possible to smoothly run a world upgrade on a 4
months old system which doesn't even have a complicated package list:
On Wed, 03 Nov 2021, John Helmert wrote:
| https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
|
| Upgrade path for old systems
| ----------------------------
| Vote (unanimous): The ebuild tree must provide an upgrade path to a
| stable system that hasn't been updated for one year.
Does "upgrade path" imply a simple world upgrade is all that should be necessary to upgrade the system? I wouldn't interpret it this way.
That a "simple world upgrade" was meant is very clear from the full
meeting log, and from the log of the previous 2009-10-12 meeting (open
floor section).
On Wed, 03 Nov 2021, Andreas K Huettel wrote:
The mistake was to allow the use of EAPI=8 too early. In the future,
we should have a new EAPI supported by portage for at least some
months before the EAPI is even used in the main tree. Not even
speaking about stable here.
On Wed, 03 Nov 2021, Andreas K Huettel wrote:
The mistake was to allow the use of EAPI=8 too early. In the future,
we should have a new EAPI supported by portage for at least some
months before the EAPI is even used in the main tree. Not even
speaking about stable here.
I tend to disagree. Adding an ebuild with a new EAPI cannot break
anything, because it will simply be invisible to old package managers.
On 3 Nov 2021, at 20:16, Rich Freeman <rich0@gentoo.org> wrote:
It probably would be good to get these policies documented someplace
OTHER than the council decision logs. I do remember the discussion
from the distant past but it is worth having it in a more prominent
place, especially since a one year stable update path is not going to
happen by accident.
I was thinking that it matters way more that @system is updatable than
world in general, since @system can be used to bootstrap everything
else. However, I think this distinction really doesn't make much of a difference. If your system can't be smoothly updated, it is unlikely
to be due to some leaf package like a browser/MUA/etc. Most likely it
is due to a widely-used dependency.
So, by all means require @world to be updatable, but I think that if
you focus on the packages in @system you'll basically get the rest for
free.
EAPI 8 came up in a later email and to consolidate replies I'll just
say that the issue isn't so much adopting EAPIs in newer packages, but
the rush to tidy up old ones that creates the problems.
Having QA tools detect this would be ideal, but right now they could
only reliably detect things like newer EAPIs in @system. Since we
don't require putting @system dependencies in packages there is no way
for a QA tool to tell what is or isn't needed to update portage. Then
you have more complex situations like PYTHON_TARGETS, and probably
others as well. I had one host that struggled a bit with the xcrypt
update for some reason (some weird preserved libs issue or something - libcrypt was still showing up as owned by glibc after updating it and
I had to override collisions to get xcrypt to install). When
upgrading a system that is completely up to date requires careful
following of news items it is going to be painful to execute a whole
bunch of updates at once.
On 3 Nov 2021, at 15:03, Thomas Deutschmann <whissi@gentoo.org> wrote:their system when they do world upgrades just once a year (remember: in my case the last world upgrade is just 4 months old!). If they cannot upgrade their system without manual intervention, we failed to do our job.
Hi,
it is currently not possible to smoothly run a world upgrade on a 4 months old system which doesn't even have a complicated package list:
[snip]
This is not about finding solution to upgrade the system (in this case it was enough to force PYTHON_TARGETS=python3_8 for portage). This is about raising awareness that Gentoo is a rolling distribution and that we guarantee users to be able to upgrade
Situations like this will disqualify Gentoo for any professional environment like this will break automatic upgrades and you cannot roll individual fixes for each possible situation via CFM tools like Salt, Ansible, Puppet or Chef.
It would be very appreciated if everyone will pay more attention to this in future. We can do better. In most cases we can avoid problems like this by keeping older ebuilds around much longer for certain key packages to help with upgrades.
Am Mittwoch, 3. November 2021, 22:39:41 CET schrieb Ulrich Mueller:
On Wed, 03 Nov 2021, Andreas K Huettel wrote:
The mistake was to allow the use of EAPI=8 too early. In the future,
we should have a new EAPI supported by portage for at least some
months before the EAPI is even used in the main tree. Not even
speaking about stable here.
I tend to disagree. Adding an ebuild with a new EAPI cannot break
anything, because it will simply be invisible to old package managers.
Except that you need to keep track of version dependencies across the whole tree.
So, yes, this is in principle correct, and in practice with our current tooling more or less impossible to do reliably.
[Part of the output Whissi pasted was (more or less) that a Perl upgrade required a rebuild of Perl modules. Unfortunately, even a single one that
is not available for rebuild makes the emerge bail out.]
--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
On Wed, 03 Nov 2021, Aaron Bauman wrote:
I love digging through old council logs to find "policy"
Not sure why others don't feel the same way.
Patches for the devmanual are welcome.
On 3 Nov 2021, at 23:53, Aaron Bauman <bman@gentoo.org> wrote:
Is that where the policy belongs?
If so, shouldn't the council update it based on their decisions?
"patches are welcome" doesn't fit every scenario.
On 3 Nov 2021, at 23:53, Aaron Bauman <bman@gentoo.org> wrote:Got to agree here. If there's a gap in the documentation,
Is that where the policy belongs?
If so, shouldn't the council update it based on their decisions?
"patches are welcome" doesn't fit every scenario.
let's file a bug -- irrespective of if someone is going to give
a patch.
Just commenting this on the ML means it'll get lost
and we'll forget about it...
On 4 Nov 2021, at 00:02, Sam James <sam@gentoo.org> wrote:
On 3 Nov 2021, at 23:53, Aaron Bauman <bman@gentoo.org> wrote:Got to agree here. If there's a gap in the documentation,
Is that where the policy belongs?
If so, shouldn't the council update it based on their decisions?
"patches are welcome" doesn't fit every scenario.
let's file a bug -- irrespective of if someone is going to give
a patch.
Just commenting this on the ML means it'll get lost
and we'll forget about it...
Filed https://bugs.gentoo.org/821553. Please
feel free to clarify it.
On Thu, Nov 04, 2021 at 12:09:28AM +0000, Sam James wrote:
On 4 Nov 2021, at 00:02, Sam James <sam@gentoo.org> wrote:
On 3 Nov 2021, at 23:53, Aaron Bauman <bman@gentoo.org> wrote:Got to agree here. If there's a gap in the documentation,
Is that where the policy belongs?
If so, shouldn't the council update it based on their decisions? "patches are welcome" doesn't fit every scenario.
let's file a bug -- irrespective of if someone is going to give
a patch.
Just commenting this on the ML means it'll get lost
and we'll forget about it...
Filed https://bugs.gentoo.org/821553. Please
feel free to clarify it.
Thank you! Many of us apparently have differing interpretations of the
policy (and it's somewhat hidden), so a clear policy in an obvious
place will be a huge improvement!
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 44:20:56 |
Calls: | 6,648 |
Files: | 12,193 |
Messages: | 5,329,704 |