[HN Gopher] I like gentoo's package deprecation process
___________________________________________________________________
I like gentoo's package deprecation process
Author : edward
Score : 95 points
Date : 2023-11-05 14:15 UTC (8 hours ago)
(HTM) web link (artemis.sh)
(TXT) w3m dump (artemis.sh)
| creer wrote:
| That is nice and often gives more than one month's notice.
|
| What is really not nice is the obession with pruning the versions
| for each package. For a specific package, there is no serious
| issue with keeping several old versions hanging around in the
| package tree. By default the package manager understands that and
| the user doesn't see them. But where there is some compatibility
| or build issue, the user would have the option of masking the
| latest and keep going on an earlier version: it would still
| build, usually with no extra effort. It would rebuild fast if you
| have a build cache. You could downgrade easily if you discover an
| issue weeks later.
|
| But no: most maintainers where that matters delete the previous
| version as soon as the new one is half in. Not a helpful
| obsession.
| noobermin wrote:
| This is what made me leave gentoo, I would have to constantly
| remove or rebuild things that just worked fine and had no
| issues. I really didn't like the constant churn with gentoo so
| I left after using it since 2009.
| djbusby wrote:
| It's not a difficult process to maintain your own repo overlay
| that keeps old packages for longer than the mainline.
|
| One reason they are trimmed is because old version of $package
| don't build with new version of $library which is a big
| dependency (eg vte) that is moving forward so keeping the old
| ones, and maintaining them gets more and more difficult as time
| moves on. It's not Gentoo forcing the churn, it's the things
| Gentoo packages that are churning and it becomes visible at the
| Gentoo layer.
|
| But your own overlay, or just pinning your build can easily
| solve that (eg, still using PostgreSQL 9)
| creer wrote:
| It's easy to copy things into your own overlay IF you get
| notice that this version is going away.
|
| Rarely, you might need to keep a dependency around. But no,
| usually the earlier packages still build just fine for a very
| long time. In the case of a high-churn package like chromium,
| there is a reason to be on latest - all the security patches
| - but when the latest doesn't build, the previous one is
| already gone (and would have built just fine.)
| Sembiance wrote:
| I've made many a trip to the git repo to dig up older
| versions and copy down the old version ebuilds into my own
| overlay: https://github.com/gentoo/gentoo
| david_draco wrote:
| I was also put off by that, but consider the maintainers
| perspective: The more versions, the more combinatorics (also
| considering install time), which means more ways for bugs to
| occur. Then someone files a bug, does not give all the
| dependencies' versions, once you have them ... there is little
| a maintainer can do with limited time when upstream says
| "update to the latest version we released". Old versions are
| remembered in the git repo history of the package tree IIRC.
| creer wrote:
| It's not unfair of the maintainer to only maintain the
| current versions. That would be fine.
|
| Old versions (ebuilds and patches) are really not easy to
| find once they are gone from the portage ebuild tree. I still
| don't know where they live.
| Sembiance wrote:
| If you go to an earlier commit here, you can find earlier
| versions: https://github.com/gentoo/gentoo
| joecool1029 wrote:
| Speaking as someone that maintains some old and dropped
| shit in my own overlay and GURU (
| https://cgit.gentoo.org/repo/proj/guru.git ), the web
| archive and Gentoo's own git history are where I usually
| find old ebuilds. They are of limited use, too old and it's
| ancient EAPI where ebuild style used to be more
| complicated, most of the time it just makes sense to
| rewrite the ebuild in EAPI 8 if needed. The main things I'm
| looking for are the notes and stuff like custom initscripts
| that might have been written.
|
| If a dropped package is of interest and there's a reason it
| shouldn't be in the tree I usually submit it to GURU. If I
| use it and it probably should be saved or re-added to the
| tree I proxy maintain it.
| creer wrote:
| Thank you @Sembiance and you!
|
| When I somehow get to an old ebuild like perhaps
| gentoo/www-client/chromium /chromium-118.0.5993.54.ebuild
| here:
|
| https://github.com/gentoo/gentoo/blob/3fb0eea1ee35033113d
| 7af...
|
| how do I find which gentoo portage 'files' were live at
| the time? (poor example - there may have been no change
| in this case.)
| joecool1029 wrote:
| Checkout the commit? You'll have a local copy of the tree
| exactly as it was at that time.
| creer wrote:
| Thank you! I don't live in git and this helps! Normally
| under gentoo I shouldn't have to. This actual git
| https://github.com/gentoo/gentoo (as opposed to the
| gentoo browser view) plus this "checkout the commit"
| should get me much further. ... And probably deserve some
| space in the gentoo docs.
| jchw wrote:
| Yeah, this is nice. I bet something like this could easily be
| brought to systems like Arch/Pacman and NixOS/Nix if someone
| wanted to champion coming up with an implementation for those
| systems.
|
| (Actually, this is definitely doable on Nix, since there are
| mechanisms like "insecure" packages, but 1. I dunno if there's
| any for this situation (block package without explicit
| confirmation because it's not maintained) 2. I don't _think_
| there 's any policy for this, but it would be nice if there was
| at least a procedure for people who _wanted_ this kind of
| deprecation. It 's also a bit different on Nix since it is not a
| rolling release distribution.)
| nmstoker wrote:
| Completely agree. This seems a really nice approach in Gentoo.
| Am a big fan of Arch but I was immediately thinking this would
| be handy there - I'm pleased with the engagement/responsibility
| that Arch encourages but this kind of thing is always catching
| me out and I pay a fair amount of attention to my
| installations!
| VTimofeenko wrote:
| NixOS recently introduced "problem" infrastructure to deal with
| such problems more gracefully and explicitly:
|
| https://github.com/NixOS/rfcs/blob/master/rfcs/0127-issues-w...
| herpderperator wrote:
| Gentoo was my first proper Linux distro that I started using over
| a decade ago. As the time has gone by and I ended up using other
| distros for other purposes, I got exposed to the ways the other
| distros do things... which I often found to be unintuitive or
| confusing compared to Gentoo. It made realised just how lucky I
| was that I started off with a distro that pays such close
| attention to detail to so many things - like the one in the post.
| Gentoo was definitely one of the main reasons I found so much joy
| in Linux and resulted in the career that I have today.
| Xiol32 wrote:
| A comment I could have written word for word.
|
| Not hyperbole to say that Gentoo set the course of my life. I
| don't use it anymore, but I'll never forget my time with it.
|
| Long may it continue.
| NotYourLawyer wrote:
| What do you use now? Why'd you change?
| Xiol32 wrote:
| Fedora. I use Linux for work and have kids, don't have the
| luxury to tinker as much as I used to.
| Zetobal wrote:
| My old Athlon could write books about failed compilations and
| 13 year old me fudging up every config file.
| Xiol32 wrote:
| Plenty of arguing with my parents to let me leave the
| computer on overnight to finish compiling KDE 3 on a
| Pentium 4.
| darkwater wrote:
| Here another one o/
|
| I got my first job in the web world because I was using
| Gentoo at home, and that totally defined my career as well.
| The day I build again a desktop computer, I think I'm going
| to install it again (although waking up at 4AM to check why
| the kernel or Konqueror weren't compiling and fixing the flag
| or dependency issue is certainly something I will not do
| again)
| sigwinch28 wrote:
| Gentoo was how I was introduced to Linux, too.
|
| A Dutch friend on a filesharing IRC network walked me through
| an install process on my old laptop, via Skype, throughout an
| entire evening and some of the night. I remember how we went
| through one-by-one enabling certain kernel modules and reading
| the descriptions of what they did.
| alpaca128 wrote:
| I recently installed Gentoo for the first time and I like it
| too. The installation process may be long but I think that's
| actually a strength if you're part of the target audience. The
| handbook is not just an installation guide but also an
| effective introduction to how Gentoo works and it just feels a
| bit more transparent to use.
| ipaddr wrote:
| Started off with CentOS and I'm still recovering.
| hotnfresh wrote:
| Having extensively used Gentoo on the desktop (laptop, even!)
| mostly just makes me grumpier at all the time and money we
| waste doing shit our OS could do for us with way less effort.
| But nobody likes those solutions these days, they want to re-
| invent system services as fragile, fiddly crap with a Web
| dashboard.
|
| It's handy to know because sometimes I can save day, but mostly
| just means I can name the older, better thing we're spending a
| dump truck of money to do the hard, worse way.
| res0nat0r wrote:
| I think a lot of the reason why I don't use Gentoo anymore is
| because the time I have to waste when I have to compile
| Chrome from scratch and wait two hours vs. just installing a
| precompiled .deb archive. :)
| speed_spread wrote:
| I'm pretty certain you could just select the binary version
| of Chrome. Most large apps have a precompiled package:
| LibreOffice, Firefox...
| thomastjeffery wrote:
| I don't even use Gentoo, but I still extensively use its wiki.
| The Gentoo Handbook is the best documentation I have ever
| encountered.
| qwertox wrote:
| I agree, this is great. How does Debian do it?
|
| One thing I liked about Ubuntu was how they handled the Python 2
| -> Python 3 transition after version 2 was officially no longer
| supported.
|
| `python` was then a non-existent command which would fail while
| python3 continued to work.
|
| This way one would not accidentally run a Python 2 script which
| kind of worked with Python 3 but then failed under very specific
| circumstances, possibly even after running for a couple of days.
| Not even letting that script start in the first place directly
| after the distro upgrade was the correct thing to do.
| bduffany wrote:
| There's a pretty popular `python-is-python3` package in Ubuntu
| which aliases `python` to `python3`. I used to install that in
| my dev environment setup scripts, but have since stopped using
| it for the reasons you mentioned. I've found it best to think
| of Python 2 and 3 as totally separate languages, so I consider
| it a good thing that the binary name python3 is unambiguous in
| all contexts.
| yjftsjthsd-h wrote:
| It makes more sense to support that as an opt-in rather than
| making the default, I would think
| pzmarzly wrote:
| AFAIK the packages in Debian/Ubuntu world should only be
| removed on major OS release (Debian 9 -> 10, Ubuntu 22.04 ->
| 22.10, etc).
|
| I think that if you upgrade the OS by just changing repo URLs
| in apt config, the old packages will stay installed - so it
| will be just like in Arch situation described by the author.
|
| For Ubuntu, their do-release-upgrade script asks you to remove
| packages that didn't make it to next release.
| https://askubuntu.com/questions/1392819/do-release-upgrade-h...
|
| EDIT: you can find obsolete packages on your system using apt
| or aptitude https://askubuntu.com/questions/98223/how-do-i-get-
| a-list-of...
| goodpoint wrote:
| > How does Debian do it?
|
| Debian guarantees than no package is removed from a release
| during its entire lifetime. This is why it's called Stable.
|
| This can be extended to 5 years if you use LTS and up to 10
| years if you use ELTS (but it's an external commercial service)
| ipaddr wrote:
| Then you are stuck with tutorials / instructions looking for
| python instead of python 3 until you just alias python 3 back
| to python.
| creer wrote:
| Also notable is that such a deprecation notice is not fatal:
| usually one maintainer or group of maintainers have decided - but
| that's based on their own view of needs vs headache.
|
| A user can easily (often) continue maintaining a local copy -
| just for their local habit. First just with the current version
| of the software. And nothing prevents them from taking over as
| public maintainer for Gentoo. Either as a mainstream package or
| in one of the many unofficial repositories. This is all helpful
| as package system features.
| lifeisstillgood wrote:
| Ultimately all sets of packages are a consensus - either a
| company says "we only use these versions of these languages and
| libraries" or it's a whole community. (This honestly beats the
| laissez faire approach which always blows up somewhere)
|
| It's something companies shoukd consider doing internally as well
| - this API is supported at this version etc. It's easier to do
| explicitly than implicitly (large companies usually have internal
| SLAs and actual written docs)
|
| I think the point I am making is good deprecation is part of good
| contracts.
| NotYourLawyer wrote:
| > If I run any package manager operations between the mask date
| and one month after the mask date, I'll get this comment telling
| me the package is masked. After a month though, the package will
| get removed from tree along with the package mask (no need to
| mask a package which isn't there anymore). So I won't get the
| helpful message if I happen to go more than a month between
| system updates. Which I think is a fairly generous window.
|
| A _month_ is generous? I mean maybe for my desktop machine.
| Certainly not for some headless file server.
| theamk wrote:
| > So I won't get the helpful message if I happen to go more than
| a month between system updates. Which I think is a fairly
| generous window.
|
| Gentoo was my first Linux distro and it was cool.. It definitely
| taught me a lot about app building. But the expectation that
| every machine needs to be continuously updated at least once per
| month is what caused me to go to Debian. You have that server
| which just works and you haven't logged in there for three
| months.. or a laptop which you only use for travel? Prepare for
| broken automated updates and careful package rebuilding in just
| the right order.
| IntelMiner wrote:
| I sometimes half-joke that Gentoo is the only Linux distro I can
| "tolerate" using. Mostly as I've always been the affectionate
| butt of jokes from other Linux using friends
|
| After using Gentoo for about 15 years at this point every time I
| try to use another distro it just feels deeply unintuitive and
| backward.
|
| Some of the examples I often cite:
|
| If I want a package in Gentoo, I just run "emerge -av [package]"
| if need be I can alter its USE flags under
| /etc/portage/package.use/[package-name] and get _exactly_ the
| features I want and need, and nothing else.
|
| If that package doesn't exist, Gentoo's portage has a system
| where it suggests "similar" sounding packages. Like if you try to
| emerge "firebox" instead of "firefox" it will offer it as a
| correction
|
| If I want a package in Debian/Ubuntu conversely, I type "apt-get
| -y install [package]" and sometimes find that oops that's not the
| package I want, or that package doesn't exist under that name!
|
| Then I try searching for that package via aptitude, getting a
| litany of "libpackage3/5/7/9" or libpackage-something-something-
| dev libpackage-something-something-doc libpackage-something-
| something-headers and so on. It's all just very messy. There's
| also rarely any description as to what the package _is_ without
| googling it beforehand
|
| For many years I used Chromebooks as my portable Linux PC of
| choice. My rationale at the time being that Google mandated no
| "binary blobs" in the kernel and that all hardware support must
| eventually land in the upstream kernel. Along with hiring the
| entire Coreboot team these made extremely attractive (albeit
| cheap and disposable) laptops
|
| Some of the hardware support (keyboard backlighting, trackpad
| etc) weren't yet in the mainline kernel. On a binary distro I
| would have to source out (or build my own) patched kernel
| manually to add this hardware support
|
| Gentoo due to being source based provides an entire mechanism for
| just this, under /etc/portage/patches
|
| This feature isn't exclusive to the kernel either. Any package
| you want on a Gentoo system can include any number of custom
| patches you desire as a user. I've used this feature additionally
| for enabling things like Intel ARC GPU hardware encoding support
| under ffmpeg while it was still in development
|
| Gentoo's biggest draw for me however is its philosophy and
| dedication to "choice". Not choice in the traditional sense of
| "we have lots of desktop environments to pick from". Choice is
| etched into Gentoo's very bones by its nature as a source based
| distribution.
|
| When briefly setting up a temporary NAS at a friends house I
| opted to simply use Fedora, thinking it would be easier than
| spinning up a full install of Gentoo for such a short-lived
| purpose
|
| Installing Fedora and Samba I grabbed my smb.conf from home and
| used it as a template to set up the NAS. After starting it up I
| found no success in writing to the drives. I had correctly
| configured them in /etc/fstab, added the appropriate users and on
| a whim even tried chmodding the mount point just to rule that out
|
| After a lot of googling it seemed that Fedora's _SELinux_ was the
| culprit. I 'm not interested in debating the merits of its
| inclusion or not, indeed I agree SELinux is a powerful security
| toolkit.
|
| I bring it up purely to highlight Gentoo's difference in ethos
| and why I'm personally drawn to it. Gentoo never "does" anything
| for you on its own. It does not try to make any assumptions or
| guess your intentions as a user. I liken Gentoo to being given a
| bucket of Lego bricks. You have a vision in your head for what
| you want your system to do, and how to do it. So you build it to
| those specifications brick by brick.
| richardwhiuk wrote:
| > If that package doesn't exist, Gentoo's portage has a system
| where it suggests "similar" sounding packages. Like if you try
| to emerge "firebox" instead of "firefox" it will offer it as a
| correction
|
| This exists in Ubuntu/Debian - if you type `firebox` you
| literally get: $ firebox Command
| 'firebox' not found, did you mean: command 'firefox'
| from deb firefox (1:1snap1-0ubuntu2) Try: sudo apt
| install <deb name>
| IntelMiner wrote:
| Is that if you try to _run_ the command, or install the
| package?
| Given_47 wrote:
| > Gentoo's biggest draw for me however is its philosophy and
| dedication to "choice".
|
| Same. I remember when I was going through the install handbook
| its three stated "design principals [sic]" of openness, choice,
| and power [0] spoke to me.
|
| > I liken Gentoo to being given a bucket of Lego bricks.
|
| I recall seeing some comment (might've been ascribed to Daniel
| Robbins, not sure) about how "Gentoo was created to be LFS for
| humans."
|
| [0]:
| https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Abo...
| o11c wrote:
| Not just deprecation - there is _so_ much about Gentoo 's
| packaging tooling that is very nice.
|
| It's a pity that other distros refuse to learn from it since they
| think its ideas must be limited to source-only distribution.
| randyrand wrote:
| I like how Dart does it with pub.dev
|
| - packages are forever
|
| - they cannot be deleted
|
| * with rare exception ofc
| JohnFen wrote:
| I do like that!
|
| > After a month though, the package will get removed from tree
| along with the package mask (no need to mask a package which
| isn't there anymore).
|
| Does this mean that the package manager will just remove the
| package on its own automatically? If so, I take great exception
| to that. Removing packages like that should always involve overt
| user interaction.
| light_hue_1 wrote:
| No. It will not remove your local copy. But you can request it
| to do so.
___________________________________________________________________
(page generated 2023-11-05 23:00 UTC)