Live data from Hacker News

Debian Packages That Need Lovin'

wnpp.debian.net

11–20 of 151 posts

Re: Debian Packages That Need Lovin'

#11
Isn't it worrisome that something like openssl is listed as having no owner? Wouldn't a sneaky patch in something as low-level and widely-used as that have devastating consequences?

Is there another Linux distro that gets multiple eyeballs on (core) package changes and proper security reviews that you folks would recommend for daily driver?

Re: Debian Packages That Need Lovin'

#12
post #2

holy shit, order by installs, Apache and sudo have no maintainers

Apache makes sense - it's a bit of a mammoth with complex packaging (as different components arrive in different packages). A cruise through the relevant list thread shows he's looking for a gradual handover, soliciting help, but being suitably picky about who takes over (eg, eagerness isn't the only job requirement).

Do click on the package titles to go through to the relevant thread. For most the packages you'd be worried about, what you'll see is either a well-reasoned handover of responsibilities, or a simple call for help.

(Or just look at the 'type' column - RFH is Request for Help, RFA is Request for Adoption. Important or complicated packages looking for more team members isn't a panic.)

Re: Debian Packages That Need Lovin'

#14
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. It’s a really well thought out system and I am surprised it isn’t more widely used. By contrast Docker seems to be more portable but way more of a pain in the ass.

Re: Debian Packages That Need Lovin'

#15

I have been using Debian on and off since the late 90s, including some time creating packages. It was wonderful to be able to install a recent, working version of pretty much anything you wanted for the vast majority of that time. More recently, so many things I want to use are not available as a reasonably up-to-date package. Some examples are hugo and eclipse, where the versions provided are unusably ancient. https…

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 search for Arch packages returns about 50 results.

https://packages.ubuntu.com/search?suite=groovy&section=all&...

https://aur.archlinux.org/packages/?O=0&SeB=n&K=rofi-&outdat...

AUR packages look easier to maintain than PPAs, so I'm more likely to get get involved with packaging something on Arch then I was on Ubuntu.

Re: Debian Packages That Need Lovin'

#16
post #4

Anyone else disturbed by this? These packages have root access for millions of computers and thousands of Fortune 500 companies and no one is maintaining them?

If you aren't volunteering, don't be surprised that other people aren't either.

Asuming that only self-funded individuals can contribute in their spare time, but companies can dedicate staff too.

Re: Debian Packages That Need Lovin'

#18

I have been using Debian on and off since the late 90s, including some time creating packages. It was wonderful to be able to install a recent, working version of pretty much anything you wanted for the vast majority of that time. More recently, so many things I want to use are not available as a reasonably up-to-date package. Some examples are hugo and eclipse, where the versions provided are unusably ancient. https…

I think the future is probably something more NixOS-like. Now, personally, I've tried it and found it a bit wanting UX-wise (and for really niche stuff), but for providing cutting edge and the ability to roll back safely I don't think it can be beaten. If you have databases, etc. that might need to be rolled back things get more complicated, ofc.

Right now, I'm running Arch Linux with a small smattering of self-compiled stuff. Arch seems to actually be pretty stable, unless you're using their 'testing' repos... and it's very close to bleeding edge. Their secret, I think, is staying as-close-as-possible to upstream -- the trouble usually starts when distros start to add large patches. This has been a huge issue for me with Debian/Ubuntu.

Re: Debian Packages That Need Lovin'

#19

I have been using Debian on and off since the late 90s, including some time creating packages. It was wonderful to be able to install a recent, working version of pretty much anything you wanted for the vast majority of that time. More recently, so many things I want to use are not available as a reasonably up-to-date package. Some examples are hugo and eclipse, where the versions provided are unusably ancient. https…

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…

> After using Ubuntu for over a decade, I switched to Arch Linux.

Hah! Very similar experience; see my sibling reply :)

Re: Debian Packages That Need Lovin'

#20

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”.
Post reply on HN