I once built a whole deployment system out of packaging all our services as Debian packages and running them out of our own apt repo. Once we got it working, this was a really low maintenance system and bringing new servers online was stupid easy. Since then Debian packages have become easier to create and maintain. And it’s a great skill if you ever need to create e.g. a custom-compiled version of nginx or some such…
Being able to uninstall something with more than file is enough reason for deb packaging for end user software. Server software isn’t as relevant as the shift to containerized work loads as made server configurations “build once and toss”.
Debian Packages That Need Lovin'
61–70 of 151 posts
Re: Debian Packages That Need Lovin'
#62I once built a whole deployment system out of packaging all our services as Debian packages and running them out of our own apt repo. Once we got it working, this was a really low maintenance system and bringing new servers online was stupid easy. Since then Debian packages have become easier to create and maintain. And it’s a great skill if you ever need to create e.g. a custom-compiled version of nginx or some such…
I'm helping with building that part at my current job and the main problem that I'm finding is that the documentation is not good at all. There's a lot of trial and error, outdated documentation and such that makes it hard to get started. I do agree that once it's setup properly with a CI pipeline, it becomes a breeze to install and maintain updated systems.
Re: Debian Packages That Need Lovin'
#63This is an off topic question, but is Debian a good alternative to Gentoo? Over the last three years I'm assuming Gentoo is so low on resources that they are just removing packages left and right. Every few months my install is broken due to this. The main reason I'm still with gentoo is inertia and I really like the tools and just the way things work. The problem really is the portage tree (basically the repo) which…
Re: Debian Packages That Need Lovin'
#64This is an off topic question, but is Debian a good alternative to Gentoo? Over the last three years I'm assuming Gentoo is so low on resources that they are just removing packages left and right. Every few months my install is broken due to this. The main reason I'm still with gentoo is inertia and I really like the tools and just the way things work. The problem really is the portage tree (basically the repo) which…
I think that's a trick question, Debian's outdated but stable binary software is in many way completely antithetical to Gentoo's philosophy, but on the other hand, it's still Linux, and absolutely a viable alternative regardless. I'd love to hear some more opinions about the state of the portage tree though, as a new and naive, but dedicated, Gentoo user, I don't have a sense of it's history or the state of the proje…
Re: Debian Packages That Need Lovin'
#65Re: Debian Packages That Need Lovin'
#66Earlier quoted context omitted.
> Yes. However, Arch Linux means you need to spend time, probably several times per year, to fix stuff that worked yesterday but doesn't work anymore. Largely a myth and config-dependent. I used to have this issue 10 years ago but now most of my troubles are self-inflicted. Things are as stable as they come when using software from the official repos.
I feel like a fairly competent Linux user and within 2 months had my Arch install broken to a point where I didn't want to invest the time to go down that "why is right click broken along with all these dependencies" rabbit hole. I went back to my mint/debian/Ubuntu safe space.
In my experience, Arch is one of the most stable OS's I've seen. But I suspect a lot of it has to do with what you're doing with it. First, ThinkPads are generally well supported in Linux. Also, I've never seen any reason to use GNOME as a desktop. I used to run XFCE on Compiz, then i3 as Compiz stopped being updated. More recently, I've switched to sway, and I've finally started using PulseAudio because it's required for Zoom. Obviously, i3 and sway aren't for everyone. YMMV.
Re: Debian Packages That Need Lovin'
#67Earlier quoted context omitted.
Yes. However, Arch Linux means you need to spend time, probably several times per year, to fix stuff that worked yesterday but doesn't work anymore. Arch Linux is just an entirely different thing compared to Ubuntu. I'd like someone who isn't me to make sure stuff works. Only very rarely will I be bothered to do actual work to upgrade to a new breaking version on my daily driver. Randomly breaking my shit on a Tuesda…
Upgrading Arch Linux can be a mess... But Ubuntu is no picnic, either. I've seen plenty of glitches during Ubuntu 20.04 "LTS" upgrades. The most recent is it dropping the network in the middle of the 20.04.2 upgrade. Before that, it lost the default route (there was a bug with multiple interfaces.) There have been others.
Re: Debian Packages That Need Lovin'
#68Earlier quoted context omitted.
After using Ubuntu for over a decade, I switched to Arch Linux. If you exclude the duplicated architecture packages in the Ubuntu repos and include the community-maintained packages, Arch has more packages new packages seem to commonly available within 24 hours of an upstream release. For example, I use some utilities based on "rofi". A search for Ubuntu packages containing "rofi-" contains just no results, but a sea…
I think arch is better for desktop sorts of things. remember: - desktop users want the latest thing, immediately. - server users want nothing to change, ever.
I want things to work. I don’t want to spend my time arguing with my tools, just for the sake of having the latest and greatest. I might go through and upgrade everything every couple of years, at most.
Beyond that, I just want security upgrades to happen without me having to think about them.
Re: Debian Packages That Need Lovin'
#69Earlier quoted context omitted.
> Their secret, I think, is staying as-close-as-possible to upstream I've wondered about this. This would depend on upstream being sane about how it does things or puts things. Is this always the case?
Usually, yes, it appears. Maintainers of projects are generally pretty invested in getting their software into popular distros... and so they tend to follow the patterns that would allow that. (I mean, stuff like 'where do I put the binaries' is still often configured in Arch and other distros, so we're talking about stuff outside of that kind of thing. Most packages aren't complicated enough to require anything outs…
I think modern package managers for programming languages show us the right approach here. A cargo binary crate can be built on any platform that rust supports, it knows it’s dependencies and the compiler flags are passed in in a consistent way. I could imagine cargo having a 1 button “publish crate to dpkg/homebrew/ etc etc” button. Or alternately, I could imagine Debian allowing crates.io to exist as part of the package namespace. Then you could “apt install crate/foo” and the “foo” package author wouldn’t have to think about dpkg at all. (Maybe this already exists? It would be a sweet way to use the ppa system.)
Re: Debian Packages That Need Lovin'
#70IMO, what really needs some lovin' is the official onboarding process for new contributors.