[split] upgrade philosophies

[figueroa]

... WOL build host
...

What is WOL in this context?

[pjp]

Wake On LAN. I want it off unless its told to come online and build something.

[Onkobu]

My computers run 24/7 and only run Gentoo. I only reboot for kernel upgrades about every 100 days or so. […]
I spend quite a bit of time in the forums participating with other users about their problems, but I rarely experience those problems.

Same here but with a lot of experience and background. If something fails I can do the one right thing instead of trying many options that make it worse. So I also prepare my frequent upgrades and for example update @system first and --with-bdeps=y @world resp. @revdep-rebuild last.

And a server not requiring qtwebengine/ gtk+/ ... is a lot more reliably to upgrade.

[pingtoo]

Also only Gentoo on my systems, 24/7, with 30-90 day updates / reboots, give or take. Although I'm hoping to go with a WOL build host and migrate some file serving to lower powered devices. For now, I have no better idea that RasberryPi's (the Zero seems interesting). If that goes well, I'd only have a single, power-hungry server for backups and large data.

I use a RasberryPi4B with 4GB ram as my desktop and 2 NanoPI R4S (also 4GB) one as my server and the other as my router. Both NanoPI run OpenWrt.

NanoPi R4S is also ARMv8 architecture, so I have a docker container load with RPI's desktop image and do all my compile on the NanoPi server.

[pjp]

Thanks, I'll definitely look into those. Until now I've avoided ARM mainly because the install process seemed more involved than I wanted. Now I'd like a smaller physical footprint.

[pingtoo]

Thanks, I'll definitely look into those. Until now I've avoided ARM mainly because the install process seemed more involved than I wanted. Now I'd like a smaller physical footprint.

From installation prospect, compare to x86/x86_64, ARM is much simpler, either it work or don't. And my experience, 99% of time it just work, the 1% usually are human mistake where typo or miss step. The only draw back are default storage are slow compare to modern x86/x86_64, depend on your usage and hardware there is always existing workaround that.

[pjp]

Interesting. Looking at the ARM forum, it seemed like it was more challenging. I'm intrigued.

[pingtoo]

Interesting. Looking at the ARM forum, it seemed like it was more challenging. I'm intrigued.

If your objective is take hardware without existing gentoo support to where you can boot, it is bit more challenge. But in the process you get to learn a lot more about Linux boot process. You also learn about cross-compile. On the other hand, a hardware with existing Gentoo support, it is not that different then take a live image flush it in to primary storage and boot. in this case usually is subsequent maintain you newly started ARM device is challenge. (Because limited CPU/Memory/Storage)

[segmentation-fault]

Finally, on Day 20 of my update hell, after countless partial updates that paved the way (compiling 1000-1500 packages...manually...) and freed it from slot conflicts and other annoyances, I was able to type my "voodoo" (as I call it, looking at its options ) command

Code: Select all

emerge -vUDua --backtrack=2000 @world-updatable

and, after more than one hour of thinking, get the offer to upgrade:

Code: Select all

Total: 1306 packages (1067 upgrades, 5 downgrades, 88 new, 23 in new slots, 123 reinstalls, 2 uninstalls), Size of downloads: 6,329,150 KiB
Conflict: 7 blocks (all satisfied)

Now, the 1 million $ question for you is...shall I say Yes, or shall I deny?

...

Forget it, just kidding - of course I said Yes!

Yes, Yes, Yes!!!

[segmentation-fault]

Forced disruptive updates is why I replaced Windows 11 with Gentoo.

I had the same annoyance with Windows 10 - both native and virtual. I fixed it by installing StopUpdates10 - no more disruptions, control is back to me.

Windows 11 is also supported, take a look. With virtualbox, you can have a virtual Windows around, for software you might want to try or use. Works wonderfully in Gentoo.

[segmentation-fault]

segmentation-fault -- Your just a messy user (100 windows open).

How can you say that...I am amazed at this demonstration of combined ignorance with arrogance...I'm sorry to say that...

I have not 100 windows open. My browser had 5 windows open, one of which had 1600 tabs open alone - so what? *That* is messy? So, to you, everybody who has "a lot" (what is "a lot"?) of something is automatically messy?

Let me tell you: one is messy if one does not have order, not if one has many things. I have a very strict order in my computer, I know where is the place of every file I have, I have procedures to put everything where it belongs (in the right folders etc.) - NOTHING lies around!

Just because one has 100 documents and 2000 web pages open does not make one messy. A reader with 100 tabs is one window and a browser with 2000 tabs is another.

But yes, I am not a fan of minimalism, if that's what you mean. I am a power user. I can use all 8 CPUs and 80 GB RAM on my laptop. Is that messy too?

I imagine Gentoo must seem hopeless to you.

I feel very at home with Gentoo. It gives me a rock solid system and can cope with all that "messiness" (complexity is the right word) effortlessly. It simply has a clear deficiency when it comes to updating a system that has gone long (say one year or more) without updates.

But, who reboots. My desktops and servers run 24/7, but I do log out almost every night.

Since I update very seldomly, I take that as an opportunity to compile a new kernel too. This forces me to also reboot. So, for me, updates and reboot go hand-in-hand.

[segmentation-fault]

Ah...I forgot: sure, even a few windows will look messy - if you don't know how to organize them!

I use a browser that can have tabs - there was a time when Seamonkey with the Multizilla plugin was the only one around with this ability. I have been using tabs since that time.

I also use a document reader that can have tabs. For PDFs, this is standard, for EPUBs and DJVUs not. I thus often find myself opening such files in the browser too - with the right plugin/extension.

For editors, I use vim/gvim and make heavy use of the :b command to switch between "buffers" - practically like tabs.

For X terminals, yes I use tabs for them too! I use xterm and I open one with[1]

Code: Select all

tabbed -g 1250x500 -c xterm -ls -geometry 100x22 -into &

(final geometry will be 100x22 in this example, so don't worry). To open a new "tab" in this xterm, I press Shift+Ctrl+Enter. To switch between them, I press Shift+Ctrl+L (forwards) or Shift+Ctrl+H (backwards). See 'man tabbed' for details.

I never manage to read a document from start to end, so most of the time I keep it around and come back to it later.

Since I switch from programming to compiling to reading to searching the internet and back again all the time, day and night, during a 300+ day uptime period quite a few documents/tabs remain open for a long time. I once had an ALSA problem - searching for it took 1.5 months(!) and 120 tabs, thousands of lines of notes, many .conf files and who knows what else. That's true life, if you want to use your system the way you want it, not the way it wants you to use it.

To cope with all this, I have ~30 virtual desktops, divided in three groups. Each group has the same background, which takes its images from a different thematic subject. Each window has its place in one of those desktops. I always know which virtual desktop to open to continue whatever I was doing there. The FvwmButtons module of fvwm shows me a very compact overview of the desktops - I only have to click on one and I switch!

If any one here feels warm cuddling with one window, one tab, one editor, one open file and one desktop (and daily updates, just to keep the perceived complexity at a minimum), that's OK with me - but please DON'T EVER EVEN THINK that your own small world must be everyone's darling, just because it's yours.

---
[1] not exactly with that command, but with something that is practically equivalent to it.

[figueroa]

I withdraw the word "messy." From your description, you may be the ultimate "messy-desk I know where everything is so don't touch it" user. Your desktop workflow sounds like a near disaster area. I can't think of anything positive to write.

I believe you are out-of-sync with portage best-practices (if there were such a list of best practices -- maybe there should be), and would definitely be in line for a Linux system admin worst practice award in the operating system maintenance category.

Children (and newer users), please don't try this at home. As the system administrator of your own Gentoo installation, please keep operating system reasonably current to avoid security issues and update difficulties. Those who choose to install updates infrequently will often encounter blockages and difficult to solve package dependencies that may lead to nightmarish update scenarios sometimes called "dependency hell." And be careful out there.

[segmentation-fault]

I withdraw the word "messy."

OK, no problem.

From your description, you may be the ultimate "messy-desk I know where everything is so don't touch it" user. Your desktop workflow sounds like a near disaster area. I can't think of anything positive to write.

What is the alternative? Open/close, open/close, open/close? That's...actionism. What does it bring?

There is absolutely no feeling of disaster, "don't touch it" mentality (I do touch things a lot, but I know when, why and how!), or any feeling of "being overwhelmed by...complexity?" or whatever. All is fine, really.

I do know people who would get crazy by having all this "around". They are minimalists. I know people who find that even 10 tabs in the browser are 5 too many. That's neither bad, nor good. That's how they are. But I'm not like them.

I think you confuse volume with complexity. A pile of work must not be complex in itself, it's just a pile. Given enough time and determination, you will manage it. You should not fear that.

You should fear true complexity. That's when "time" or "determination" must grow exponentially with the size of your pile in order to be able to cope with it. Now this indeed can be a problem when one updates rarely, because the dependency graph (the "pile of work" portage has to do) becomes large and time needed to resolve the dependencies grows exponentially with its size. But I say that we can cope with it and should not resign in front of it, suggesting "small piles" as a solution.

Besides, my biggest problem here has always been not knowing what to do, the lack of a clear strategy to cope with the problems, not the time portage needs to come up with an answer, or the time it takes to compile that many packages.

I believe you are out-of-sync with portage best-practices (if there were such a list of best practices -- maybe there should be), and would definitely be in line for a Linux system admin worst practice award in the operating system maintenance category.

This is very far from the truth. For one, such "best practices" are artificial, in the sense that they are dictated from a feeling of helplessness in front of a pile of work. For another, my system is in perfect shape, I don't understand how you come to such conclusions.

This is a misconception - what I call an "urban myth". People think that if someone leaves old software lying around so that portage whines about something, then the system is "broken". Let me tell you: it is NOT. Not necessarily.

Or, another misconception: people think that if you have "too many" tabs/documents open, you are somehow disorganized. Let me tell you: you are NOT. Again, not necessarily.

Children (and newer users), please don't try this at home. As the system administrator of your own Gentoo installation, please keep operating system reasonably current to avoid security issues and update difficulties. Those who choose to install updates infrequently will often encounter blockages and difficult to solve package dependencies that may lead to nightmarish update scenarios sometimes called "dependency hell." And be careful out there.

That's FUD (Fear, Uncertainty, Doubt).

Was I "hacked" because I did not update for 1 year and 250 days? No. I do take my precautions.

Is "dependency hell" my problem? No. It's portage's difficulty in offering clear strategies and tools. Maybe a lot of them is already there, but the clarity is missing - and with it, the strategy too. So people feel lost in this scenario. Is that a reason to avoid it - or a challenge to find true solutions and strategies?

I would say: DON'T FEAR to use your system as you please! It's you who should decide when, what and why! Of course, you should know what you are doing - but yes, ALL of these "problems" can be resolved. My message is one of optimism, not fear.

A message with a vision for a bright future - one where update frequency is irrelevant, where only tools and strategies matter.

[segmentation-fault]

So people feel lost in this scenario. Is that a reason to avoid it - or a challenge to find true solutions and strategies?

This can be split in two parts:

• What _portage_ can do for us - Example (one of my 700 tabs that I did not read to the end ):
  
  GLEP 73: Automated enforcing of REQUIRED_USE constraints
• What _we_ can do for portage - Example:
  
  Create a guide with solutions to common problems encountered in infrequent updates.

In JFK's spirit ("ask not what your country can do for you – ask what you can do for your country"), we might start work on the latter.

[pjp]

Forced disruptive updates is why I replaced Windows 11 with Gentoo.

I had the same annoyance with Windows 10 - both native and virtual. I fixed it by installing StopUpdates10 - no more disruptions, control is back to me. :)

Windows 11 is also supported, take a look. With virtualbox, you can have a virtual Windows around, for software you might want to try or use. Works wonderfully in Gentoo.

I meant Widows 10. As long as MS continues collecting telemetry, uses the OS to push ads, and doesn't allow an option to control updates, I consider it unusable. I've only personally found two uses that required Windows. One required IE extensions, the other was easier to use than "translate" to Linux. I decided they weren't worth the downside of using Windows 10.

[segmentation-fault]

Maybe we can refine the second point above ("What _we_ can do for portage") even more, to include, for example:

• What package maintainers can do for portage. Example:
  
  minimal version selection
  
  (yet another tab of mine that is still open in this messy desktop )
  
  Try to find the lowest possible version for each dependency - don't automatically use the lowest version that is in the gentoo tree at the time of writing. Differentiate between "works, but we cannot support it because this version is out of the tree" and "works and we support it". Don't always choose the latter, if you can also choose the former.

Example: I had once to merge some package from some overlay. The package required the newest icu version available in gentoo. Of course, I had a somewhat older version, as I don't exactly update daily. This hard requirement of the newest, latest and greatest icu had tremendous consequences for my system though - now, to install that one package, I had to upgrade 50 other ones, because each one of them required to be rebuilt with the new icu version! I had to manually download the ebuilds of 50 other packages from gentoo into my local overlay, just for this one!

The alternative would be to spend 3 weeks to sync completely and upgrade everything on-the-spot - just as I have done now - only to be able to use one package!

When I complained to that maintainer, I was treated like an alien - how could I even dare to not upgrade every second, as the rest of the obedient inhabitants of this planet do?

C'mon...Isn't there really no other solution than that? I don't believe it. I think maintainers have a responsibility here too. Read that link I gave above, it's very well written.

[pjp]

Don't always choose the latter, if you can also choose the former.

Portage can't choose the former because it doesn't know about it. That's the point of choosing the latter. Once unsupported version isn't available, Portage can't magically determine that it is suitable for any use. Something has to determine if two different versions are actually compatible. The closest thing I know of that might help is the ZFS feature flag.

I don't have time to read the referenced link, but I skimmed a bit of it.

we realized that the principle of compatibility is absolutely essential

I would have thought compatibility to be the obvious starting point, but OK.

If an old package and a new package have the same import path,
the new package must be backwards compatible with the old package.

Sure. But there remains the need to determine that compatibility.

I didn't find the answer to that part, but I'll read it at some point. I'm curious to read about that and how they handle non-compliant software.

[figueroa]

It still comes down to WHO do you, Segmentation-fault (and others), think is going to maintain those old packages that you continue to need because you don't keep up. There are many packages in the tree with NO assigned maintainer (volunteer opportunity). Most of those with maintainers are done by volunteers. They didn't, however, volunteer to maintain your out-of-date packages.

There is Gentoo stable, which is sort of bleeding edge, keeping up with upstream development, which is the minimum of what we all signed up for when installing Gentoo. It's in the DNA.

There is also Gentoo unstable, which really is bleeding edge, along with sometimes actually being unstable. It doesn't suit my tastes. I like to be on the TRAILING edge of bleeding edge.

Finally, there is Gentoo obsolete (I made this up), and those who want that should be maintaining their own personal repository as packages drop out of the tree. Doing so is full of built in pitfalls, besides being a lot of work. I've done this. It stinks. I'm just a user. An ebuild to me is like a foreign language.

Users wanting to run a mixed Gentoo stable/Gentoo obsolete system should not blame Gentoo developers and maintainers or Portage because the Portage DNA doesn't suit their own preferred system maintenance workflow.

End of essay.

[asturm]

Rainbows and unicorns.

[segmentation-fault]

Don't always choose the latter, if you can also choose the former.

Portage can't choose the former because it doesn't know about it. That's the point of choosing the latter. Once unsupported version isn't available, Portage can't magically determine that it is suitable for any use. Something has to determine if two different versions are actually compatible.

It still comes down to WHO do you, Segmentation-fault (and others), think is going to maintain those old packages that you continue to need because you don't keep up.

Rainbows and unicorns.

It's incredible how all of you seem to be living in your own world, where whatever I say is interpreted through the filter of your own assumptions.

pjp, your assumption was that I was talking about portage. But look at the context: I was talking about the maintainers of a package. And I was talking about the choices they do. I even gave an example with icu.

figueroa, your assumption is that I am saying to keep those packages in the Gentoo tree and support them. I didn's say that! You are answering a question I DIDN'T ask. You are saying things that, even if they may be true, they are irrelevant to what I said.

Forget portage. Forget who is going to maintain old packages. I have already said (maybe not here, but in other threads and I am sure you have read it and know it): Gentoo is an overlay among others. It has some packages. It decides to throw away some old versions and include some new ones. Sometimes it decides to throw away the whole package. It also, sometimes, decides to include a totally new package. All these are decisions of the Gentoo repository (overlay, one might say). I am not here to argue about these decisions.

portage, on the other side, is a package manager that follows some algorithm.

So we have an overlay and an algorithm. The overlay has what it has. It contains what it contains. We don't argue about this. We might argue, but it's not the point here. The algorithm, on the other hand, follows some logic. I would like to change this logic a bit (for example, I would like that, when I add a package to --exclude, it will be excluded unconditionally, not excluded if it is some package to be installed), but this is also NOT the point here! I wasn't arguing about the logic of portage when I said

Don't always choose the latter, if you can also choose the former.

I was saying this about the maintainers. They should try to choose the earliest possible version of a required software that works and put that one in the dependencies of their package. They should not take the easy way to just take the lowest version in the Gentoo repository at the time of their writing!

There's a HUGE difference between the two - and it does NOT have anything to do with who is going to maintain what, or what portage knows and what it does not. Let's see it in the example I gave with icu:

The current stable version right now is, say dev-libs/icu-0.69.1-r1 from the 0/69.1 slot. Suppose I had the 0.68 version installed. Suppose also Gentoo threw v. 0.68 away from its tree because of some security issue. The current lowest version in the Gentoo tree is 60.2, but suppose, for the sake of discussion, that it was not there and the lowest version available in Gentoo were 0.69.1 - sooner or later it will be so anyway.

Now the maintainer maintains a package X (NOT icu!). Package X needs icu to run. Which version shall the maintainer take as the lowest acceptable? Shall he put

Code: Select all

>=dev-libs/icu-0.69.1

or the earliest version of icu known to work with X, even if not in the Gentoo tree anymore, say

Code: Select all

>=dev-libs/icu-0.50

? THAT'S THE QUESTION!

The question is NOT about who maintains package X - that's the maintainer we are talking about. The question is also NOT about who maintains icu-0.50 - probably nobody, but it's irrelevant! Should someone maintain icu-0.50, in order for this version to be eligible to be used in a dependency of some package, like X? Absolutely NO! Whether icu-0.50 is maintained, or not, has some severe security issue, or not, is in the Gentoo tree, or not - all these are irrelevant to the question if package X will WORK with icu-0.50, or not. If it works, I advocate to use

Code: Select all

>=dev-libs/icu-0.50

in the dependencies of package X (in its ebuild) - and definitely NOT the current, greatest and latest, supported, present in the tree, "everybody's darling at the time of writing" version 0.69.1:

Code: Select all

>=dev-libs/icu-0.69.1

!!!

Now, to answer your objection, @pjp: portage knows NOTHING about whether v. 0.50 is maintained or not. It also does NOT care if v. 0.50 is in the Gentoo tree or not. It certainly also does not give a cent whether v. 0.50 has some security issue or not. It DOES care, though, if, for example, v.0.50 has been masked due to some reason - and it will tell me so.

BUT: If I still have (for whatever reason) icu-0.68 installed and the dependency of package X on icu is given by the maintainer as

Code: Select all

>=dev-libs/icu-0.50

THEN portage will NOT complain!

If I don't have icu installed at all, portage will offer me one of its current versions to merge - that's perfect with me.

So in this case, I am NOT forced to upgrade an older icu version, just to be able to install package X. I MIGHT run some (mild or severe) security risk (icu is notorious for its security issues), but this is another subject! It is NOT the job of the maintainer of package X to enforce Gentoo's security considerations on the user! Let the user read the security bulletin, assess the risk and make his own decision! Don't mix other considerations here, because if you do, the problem becomes (almost) unsolvable!

Let's see what happens if the maintainer says to himself "well, I don't know whether icu 0.50 works with X or not - and I don't have the time to research this, so let me take the easy way and just put icu-0.69.1 as the MINIMUM requirement for X, after all, it is in the Gentoo tree, so that will work for sure!":

Code: Select all

>=dev-libs/icu-0.69.1

Does portage know anything more now? Nope. portage will do its job and check the dependencies as stated in the ebuild of package X - and it will tell me that now I need icu-0.69.1.

So now, I have to upgrade my icu, whether I like it or not, whether I find the security risks of its installed version acceptable to me or not - if I want to use package X. This is annoying enough - the maintainer of X forces me to upgrade Y for no apparent reason - only for diffuse reasons that are important to him, like

• I don't have the time to research this
• I don't have information on this
• I am too lazy to spend a minute and look at the website of upstream, where they say "package X needs at least v. x.y.z of Y to work"
• I want to enforce MY security views on everybody
• I don't care, I just take the first version in the Gentoo tree
• Don't bother me with this sh..t, I have enough to do

But it's not only this, annoying as it may be by itself alone - the dependency that forces me to upgrade icu now forces me to upgrade a few dozen other packages that must be compiled with the same icu version that is installed (this is the "built-slot" dependency problem).

Now, you might think, "where's the problem? portage will tell you to upgrade 50 packages and just say yes and all will be good!". But that may be true (may!) only for the frequent updater! The rare updater will be presented with a much bigger problem:

The versions he has in the system are out of the portage tree. Some ebuilds will not "just work". So the rare updater must now go through a whole list of icu-dependent packages and find a way to rebuild them, possibly by downloading a newer ebuild in a local overlay. Or...

...well, or he spends one month to upgrade the whole system NOW! But who is the maintainer of package X to dictate the timing of such an upgrade?

Do you see the catastrophic effect it has if you follow a

the MAXIMUM is the MINIMUM

approach to needed versions for any package X? I advocate the maintainers should (at least try as hard as they can to) follow a

the MINIMUM is the MINIMUM

approach. In our example:

the MINIMUM working version (0.50) is the MINIMUM that is set in the dependency

and NOT

the MAXIMUM (because current, in the Gentoo tree, stable and supported) working version (0.69.1) is the MINIMUM that is set in the dependency

That's what I meant by saying that the maintainers can do something for portage too.

You now see (hopefully) that your objections are irrelevant to the problem, even if they may (may!) have some merit in other contexts:

Who maintains v. 0.50 is irrelevant. Probably nobody does - and nobody should. The relevant point is that if *I*, the user, have it (or any other version >=0.50, but lower than the latest and greatest 0.69.1) installed, portage will not force me to upgrade it - unless I want to.

On the other side, portage just looks at the versions in the dependencies, as set in the ebuilds by the maintainers. portage certainly cannot "know" if v. 0.50 exists or not. It can check if it is in the Gentoo tree and it can check if it fulfills the dependency for package X. It does not (and should not) care about anything else. So it's not a problem of what portage "knows" about v. 0.50 - it's rather a problem of what the maintainer knows about it and whether HE decides it "works", or not.

Which brings us back to the big problem of what it means to say "icu-0.50 works with package X". If icu-0.50 works, but does not display some obscure language (one of the 50,000 Unicode languages) - does it "work", or not? And if some hacker can trick the user into using some obscure string to produce some buffer overflow in icu-0.50 - does it "work", or not?

These are questions that only the USER can answer - and only the user should be the one who decides them, not the maintainer of X, not Gentoo and its tree and not portage (which is totally innocent here).

I advocate a notion of "works" that is independent of other, "vertical", concerns like security, or usability. If it generally, normally works, then it "works"! Whether it still "works" if one hammers it with some strange input should NOT be the reason why I, the user, should be forced to go through an upgrade marathon, just for package X! At least upstream will usually say something about it, one just has to research it a bit - or even ask them: "what do you think, what is the lowest version of icu that will work with your software X?". Very simple.

That's what maintainers can do for portage.

And, asturm, Gentoo is about choice and what we're talking about here is the difference between being kept in chains by artificially severe dependencies and being free to make a choice.

[asturm]

If it works, I advocate to use

Code: Select all

>=dev-libs/icu-0.50

in the dependencies of package X (in its ebuild) - and definitely NOT the current, greatest and latest, supported, present in the tree, "everybody's darling at the time of writing" version 0.69.1:

Code: Select all

>=dev-libs/icu-0.69.1

And you are aware of a specific package where this is the case and are just too lazy to show it to us, or is there really no example?

Or did you really misinterpret Portage's output for necessary rebuilds after dev-libs/icu:= upgrade because Portage, through the slot operator, must enforce rebuild of all reverse dependencies, regardless how low their minimum version requirement is, to make up for the soversion change?

And, asturm, Gentoo is about choice

Right, that's code for rainbows and unicorns by people who have no idea of package maintenance.

[pjp]

...

I had several replies, but gave up on the circular descriptions.

Maybe what you want is something like the Nix package manager which installs based on hashes? I don't know if it can maintain every version indefinitely.

It otherwise seems that you expect Gentoo developers to innately know a compatibility matrix of an extremely complex set of random software. If not, then you are asking for Portage to support something that it doesn't currently support. Except you wrote that it was neither the tooling nor the maintainer, except that it is both, but not. Or something like that.

But I admit that stream of consciousness isn't something I find easy to parse and is generally in direct conflict with the color of the sky in my world.

[segmentation-fault]

And you are aware of a specific package where this is the case and are just too lazy to show it to us, or is there really no example?

First, this is an example. Second, I did have a specific package in mind when I first mentioned this as an example. Third, it was from some overlay (I wrote that). But a) I did not want to expose the maintainer, b) I cannot find the exact ebuild right now, c) I cannot find the github bug I filed where you could read the hostile answer I got from him, d) it doesn't matter since it was an example and we are talking generally anyway, e) I have never been lazy and finally...

...since you asked for an example, there is probably no need to go very far, into obscure overlays, to find one...

So here is one:

/usr/portage/www-client/firefox/firefox-91.5.0.ebuild

says

Code: Select all

system-icu? ( >=dev-libs/icu-69.1:= )

So I ask myself: will firefox 91.5.0 crash if I compile it with <dev-libs/icu-69.1 and try to start it? Maybe that's the case. Maybe there is some severe incompatibility between firefox 91.5.0 and any version of icu lower that the latest 69.1. If this is really so, I have nothing to complain about, all is fine. firefox 91.5.0 really needs >=dev-libs/icu-69.1.

I didn't check. I am not the maintainer of the firefox ebuild. I always assume the maintainer of a package has a lot more info about it than I do. So maybe indeed firefox 91.5.0 will crash if you try to compile and run it with <dev-libs/icu-69.1.

But I strongly doubt it. I guess icu-69.0 will work, as will icu-68.x and possibly even...icu-50.

Or did you really misinterpret Portage's output for necessary rebuilds after dev-libs/icu:= upgrade because Portage, through the slot operator, must enforce rebuild of all reverse dependencies, regardless how low their minimum version requirement is, to make up for the soversion change?

No, this is actually exactly what I am talking about. Package X wanted this new version of icu, so I had to upgrade icu - and with it, through portage's slot operator, dozen of other packages! But I am not complaining here about portage (I wrote that too). portage does its job. You give it something and it tells you how it can be done, if there is a way it can be done. But if you give it

Code: Select all

firefox-91.5.0 needs >=dev-libs/icu-69.1
user needs firefox-91.5.0

it will (correctly!) tell you "user needs to rebuild a few dozen other packages with the new icu-69.1 now".

The problem is not with portage here, it's with what the maintainer set as the minimum version of icu that works with firefox-91.5.0.

Suppose firefox 91.5.0 would also work with, say, my installed icu-68.0. If the maintainer had set >=dev-libs/icu-68 in the ebuild, I would not have to go through the hassle of upgrading icu and with it all other packages that slot-depend on it.

Remember, we are not talking about somebody who updates often - in such a case, this is probably a non-problem. We are talking about an infrequent upgrader, so the system might have gone >1 year without an update. In that case, setting dependencies this way forces upgrades of whole parts of the system, just because user wanted to upgrade his browser.

Just an example, no offenses meant for the firefox maintainers or anybody else, OK?

And, asturm, Gentoo is about choice

Right, that's code for rainbows and unicorns by people who have no idea of package maintenance.

Who has no idea of package management and why? Could you please explain?

[segmentation-fault]

...

I had several replies, but gave up on the circular descriptions.

There is no circular description in my postings. Show me one, please.

No, you have to look at the context. I said "maybe we can split this into..." and then I split it: there are things that portage (i.e. developers) can do for us (and I gave an example) and there are things that we can do for portage. Then I split the latter again: we, the users and we, the maintainers. So, in fact, everybody can do something (developers, maintainers, users) to make life of infrequent users easier.

Maybe what you want is something like the Nix package manager which installs based on hashes? I don't know if it can maintain every version indefinitely.

Well, why don't you leave your system without updates for, say, 700 days and then try to upgrade? Maybe you understand my problems then...

This is not about going somewhere else. This is about how we can make update frequency irrelevant, or at least less of an issue.

The majority of users (not of current Gentoo users, of all users generally) are not frequent updaters, they simply don't bother or cannot cope with the pace. So either you say Gentoo is for frequent updaters only, or you want to embrace the larger user base.

In the former case, I say that Gentoo has already chosen its users and all else is hopeless then.

In the latter, there is hope for us infrequent updaters - but then everybody must do something about it.

It otherwise seems that you expect Gentoo developers to innately know a compatibility matrix of an extremely complex set of random software. If not, then you are asking for Portage to support something that it doesn't currently support. Except you wrote that it was neither the tooling nor the maintainer, except that it is both, but not. Or something like that.

I said developers can do portage better, in one way or another, to ease the life of infrequent updaters. I am sure there is room for making things better there.

I said maintainers can also do their part of the job, possibly by trying as hard as they can to find the least restrictive dependencies for the packages they maintain. I didn't say "developers", I said "maintainers". And I didn't say "random software", I said "packages they maintain". You would expect a maintainer to know the least working version of a dependency for a package she maintains - and even if she doesn't, she can ask upstream.

Again, I am not asking "portage to support" anything. I am not asking portage to somehow "support" packages I already have installed. But portage will ask me to rebuilt/upgrade them, if maintainers don't set dependencies in a more permissive way.

In the example I gave to asturm above, firefox would force me to rebuild/upgrade dozens other packages - not directly! But indirectly, through its very restrictive >=dev-libs/icu-69.1 dependency. Had the maintainer set, say, >=dev-libs/icu-68, and had I dev-libs/icu-68 *installed*, there would be no need to rebuild (and possibly upgrade, as rebuilding may not always work in this case) all packages that slot-depend on icu.

That's not the same as asking portage to "support" those old installed packages. Saying "icu-68 also works with the current firefox" is not the same as "we support also icu-68". I think there is a misconception here. I don't want anybody to fix the problems of my installed icu-68, I will not file a bug about it and I will not come here crying if I get hacked because it has some severe security problem. But if (I say IF!) it works, then please don't force me to upgrade it, just because I want to upgrade my browser (and only my browser, not all other 4000 packages for the next month!).

I really fail to see why on earth this is so difficult to understand..