13 ms·

Debian Packages That Need Lovin'

201 points by spyc 6y ago

jrwr 6y ago
holy shit, order by installs, Apache and sudo have no maintainers
- pengaru 6y ago
  Neither of those are listed as O(rphaned), they're RFA/RFH.
- kwk1 6y ago
  Re: sudo, not exactly: https://lists.debian.org/debian-devel/2021/02/msg00234.html https://lists.debian.org/debian-devel/2021/02/msg00234.html
- soneil 6y ago
  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.)
symlinkk 6y ago
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?
- ISL 6y ago
  Seems like those Fortune 500 companies might think about making a donation or two?
- markstos 6y ago
  If you aren't volunteering, don't be surprised that other people aren't either.
  - edu-ap 6y ago
    Asuming that only self-funded individuals can contribute in their spare time, but companies can dedicate staff too.
  - ducktective 6y ago
    fair...then people shouldn't advertise debian as the most "stable" distro fwiw
    - deleted 6y ago
      [deleted]
janvdberg 6y ago
If you sort by Installs this is kind of disturbing. A lot of well known packages (Apache2 / OpenSSL / LibreOffice etc.) have no owner? https://wnpp.debian.net/?sort=installs%2Fdesc&page=1 https://wnpp.debian.net/?sort=installs%2Fdesc&page=1
- amarshall 6y ago
  I think packages listed as “RFH” aren’t unmaintained really, just requesting for help maintaining it. Clicking-through on e.g. grub2 shows a mailing list thread requesting for help from…2004. grub2 has certainly received updates in Debian since then.
- spyc 6y ago
  Column "owner" is the owner of the related issue (bug tracker ticket), not the owner of the package.
- blihp 6y ago
  Maintainers come and go over time and these things don't just package themselves.
- qpiox 6y ago
  I think the list of packages that need lovin', needs lovin' itself. It seems this list is abandonware. If you look into the details for some these packages, you will see that it is a dead discussion forgotten even by the person who initiated it, a decade ago. E.g. the discussion about Libreoffice is not about Libreoffice at all, but Apache Open Office, and you can see that there are people who have offered help, but the OP never responded to their offers. Just click on the links on the package names and read for yourself.
  - wyclif 6y ago
    When I looked at the list, my first thought was amazement that LibreOffice has no maintainer. EDIT: Previous HN discussion about LibreOffice's lack of resources: https://news.ycombinator.com/item?id=23793942 https://news.ycombinator.com/item?id=23793942
- 6y ago
pvsnp 6y ago
Aren’t canonical and other distributions upstreaming changes to Debian?
tacostakohashi 6y ago
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://lwn.net/Articles/842319/ https://lwn.net/Articles/842319/ Meanwhile, more and more software is actively hostile to packaging / distributions, and things seem to have devolved into grabbing things from random github repos, or various dedicated/language-specific package managers like npm, pip, brew, ... It's definitely annoying, seems like a step backwards, and its not clear to me whether there's some better distro i could be using, whether some funding / volunteer time could help, or the world has just "moved on" (backwards...) from the idea of a linux distribution with reasonably stable, up-to-date packages that "just work" for basic infrastructure so you can spend your time developing on your own project, instead of with the tedium of fetching and installing software and managing version compatibility problems yourself.
- markstos 6y ago
  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&arch=any&keywords=rofi-&searchon=names https://packages.ubuntu.com/search?suite=groovy&section=all&... https://aur.archlinux.org/packages/?O=0&SeB=n&K=rofi-&outdated=&SB=n&SO=a&PP=50&do_Search=Go 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.
  - Quekid5 6y ago
    > After using Ubuntu for over a decade, I switched to Arch Linux. Hah! Very similar experience; see my sibling reply :)
gigel82 6y ago
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?
- spyc 6y ago
  Column "owner" is the owner of the related issue (bug tracker ticket), not the owner of the package.
IgorPartola 6y ago
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.
- koolba 6y ago
  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”.
  - IgorPartola 6y ago
    I find that using it on the server is super nice. If you are using Ubuntu on the server anyways, why bother packaging a Docker service for anything else?
- dimator 6y ago
  What do you recommend for learning that stuff?
  - IgorPartola 6y ago
    I wish I could recommend something but I learned it years ago and I honestly don’t remember where from. I’ll try to put together a modern version of my old LUG talk on the subject to show people how to get started.
    - ivan_ah 6y ago
      Yes plz. I'd be very interested to read about this (long time Debian user, but never packaged anything). I know there is an install, postinstall, and remove scripts but don't have a clear idea of when exactly they will get called and what "interface" they must implement. It would be really helpful to have a "package lifecycle" state diagram like this https://vuejs.org/v2/guide/instance.html#Lifecycle-Diagram https://vuejs.org/v2/guide/instance.html#Lifecycle-Diagram that shows all the states and events that "fire" based on .deb scripts and metadata.
kenniskrag 6y ago
why is eclipse so many version behind the current version? I do not think it would hurt to update a little faster.
- vore 6y ago
  If there's no people volunteering to update it, then there's nobody to update it a little faster.
- qpiox 6y ago
  Why would you need a package for Eclipse. Download it is a ZIP, extract it in the location of your choice and run it from there. (Portable app) I have been using it like that almost every day for 15 years now.
  - rjsw 6y ago
    Eclipse isn't portable, somebody has to compile it for Linux, it just comes down to whether you want that done by the Eclipse Foundation or Debian people.
    - qpiox 6y ago
      The discussion here was about why a debian package for Eclipse is not up to date. My theory is that it is obviously because there is a way how to run Eclipse, without any issues and without the need of an officially tested debian package, so there is not huge demand.
      - rjsw 6y ago
        That would be fine if Linux preserved backwards compatibility, the glibc version change last year meant that some binary packages no longer run. Something like Netbeans doesn't need a debian package but Eclipse is split into lots of jar files that each depends on some shared libraries.
- yjftsjthsd-h 6y ago
  Okay, so why don't you volunteer to update it?
oneweekwonder 6y ago
Linux Standard Base recommend rpm support. But the rpm package need adoption and refers users to alien, but the alien package is orphaned. hah, looking at wikpedia it seems LSB support have been dropped by Ubuntu and Debian in November 2015.
slavik81 6y ago
If I want to help, what should I do?
- qpiox 6y ago
  Well, you need to get competent enough before you take on a role as package maintainer. For start, imagine that you are one. First, choose a package that really matters to you. On a daily basis. A package that you yourself would NEED to have it up2date the next day a new version is out. Get the source deb and try to build it. Usually it's not very hard. Then, try to do the same on all the debian variants (unstable, stable, ...) If you succeed and the package works, you have the prerequisite competencies, at least as a beginner. Then, these are some of the things that you will need to do, quite often. Change the configuration of the package description so that you can build it with a later version of the source. For all variants of the distro. Then try the same with the package dependencies, where those dependecies are not needed for other packages. Then try to push it as close towards the latest source version, as you can without breaking stuff. Once you do all that without issues and you are confident that you can use the version you built from source as a daily driver and you are not bothered by that, contact the original maintainer directly and offer help, sharing the details what you did as proof that you are competent enough. If the maintainer is uncollaborative or unresponsive, put up your own repo for public use, and invite the public to install the package from your repo, so that the public will see some benefit and you will receive zillion of bug reports to further streghten your competence level.
  - deleted 6y ago
    [deleted]
  - slavik81 6y ago
    That does seem like it would be a sensible way of going about things if I could manage to find a package of modest complexity that is important to me, but under-maintained.
    - qpiox 6y ago
      Maintaining a package is not as hard as developing software. You don't need to know algorithms, you don't need to know programming, you just need to know how to start a compiler and packaging software from the command line and read errors from the log. If you are an active developer in the language that is used it will be easier, but you can do it even if you are not. Example. Todays news here, is the latest release of Kodi. Debian does not have the most recent version. Some months ago I had an issue with the Kodi from the debian multimedia repo, so I decided to build it from source. It took me the better part of a day to have all the build tools installed and set-up everything, starting from zero. But in the end I had the latest Kodi running and it was running like that for 5 months and I even forget that I built it. I managed to do that without even looking into the source code. In fact if you ask me what programming language is used to develop Kodi - I really don't know and don't remember. Package maintainance is more about testing than about building. So a list like this can serve as a guide in the process of choosing where to help. Just sort by number of users that use the software and go down the list until you find something that you use daily and where you would like to have the most recent version available and would volunteer your effort for 2-3 years (it is not really helpful if maintainers change every couple of months).
noobermin 6y ago
This 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 is become more and more bare as the years go on. For example, I miss eix whenever I use debian, apt-cache just isn't as useful. Also, having to use not systemd is a plus and a reason I won't use Arch. Any suggestions?
- LanternLight83 6y ago
  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 projects resources.
  - LanternLight83 6y ago
    Gentoo packages, by virtue of use flags, do seem like they'd take more effort to build and maintain, but I don't know enough about gentoo packaging as I'd like to :p
    - spyc 6y ago
      I have packaged for both Debian and Gentoo; packaging for Gentoo is way easier and more fun, one reason being that (simplified) you're dealing with a single Bash file rather than a magic Makefile and things split into 20+ small files. The difference is huge.
  - noobermin 6y ago
    The thing I'm imagining is that if there was something I wanted the USE flags for, I'd just end up compiling myself in a prefix. I already do this for some packages because of the issue with Gentoo removing things they consider stale which is the problem. I don't need USE flags all the time or compiling everything with -O3 -march or whatever, for most things it's just a plus that it might be faster. I think the one thing that might actually matter for me is in Gentoo fixing broken things is more direct, just compile, while I've had issues that persist on ubuntu even after reinstalling something. It just felt like there was somehow "stale state" in my OS which even sounds ridiculous saying. But, at this point, I can't handle breaks in portage because while you can fix things, it requires mental effort on my part and I'm tired of it. EDIT: reading your comment, if you're asking for my opinion I mean look at this in particular: https://bugs.gentoo.org/420783 https://bugs.gentoo.org/420783 ioquake3 was literally removed from portage for this "bug" which even if you accept that it's a hypothetical issue has easy patches that were never included, and it was removed, essentially removing hosts of open source fpses from portage! I even read a forum post talking about "upstream" not caring...upstream? ioquake3's release was charity, it's not like an active project. This has been happening for a while. I've been here since 2008 or so and the instability and removal of slots within months has gotten out of hand. Again, the tooling is great, emerge, eix, the whole system of configuration files is awesome and I'm just used to openrc. I wish I could keep them but the slot removals in portage has just become such a chore to deal with.
jonathankoren 6y ago
Looking at orphans by installs and I remember using some of these 20 years ago, but do people even use libgpod and xmms anymore?
- notatoad 6y ago
  that's my first reaction to this list too - is a debian-specific package really providing more value than the effort of maintaining it for a lot of this software? even libgpod and xmms are relatively high-profile examples. i do appreciate being able to apt-get install some obscure package and have often wondered how it's a sustainable system that maintainers are putting in effort to package these things up into a distro for me. but maybe it isn't?
  - jonathankoren 6y ago
    I wonder if the install base is is so high because 20 years ago some package maintainer decided to put XMMS in a gnome-apps (or whatever) metapackage, and no one removed it. I don’t even know the last time I found a publicly accessible mp3 url stream, or listened to a local mp3 file. Local files had to be like 10 years ago.
crb002 6y ago
Resorted by installs https://wnpp.debian.net/?page=1&sort=installs%2Fdesc https://wnpp.debian.net/?page=1&sort=installs%2Fdesc
- spyc 6y ago
  You have a point here: I have made that^^ the new default sort order now.
cglong 6y ago
As someone who's thinking about moving to Linux and has made many non-trivial contributions to Homebrew, the contribution process for Debian packages scares me. The official documentation seems to be more of a reference guide than a tutorial, and community blog posts always seem to start with "That other tool is outdated; here's the new way to do it," making it impossible to know which method is the right one. IMO, what really needs some lovin' is the official onboarding process for new contributors.
- qbasic_forever 6y ago
  Here's something to keep in mind that isn't super clear to newcomers, Linux != Debian. Linus Torvalds doesn't use Debian and nothing Debian does really impacts him or the core of Linux. Debian is just a highly opinionated take on Linux. You can totally dive in and be super productive with Linux without ever having to know about, use or, or care that Debian exists. (oh and Homebrew works great on Linux, give it a shot as it's a really easy way to move over from OSX). Regarding the Debian package process, etc.--I'll be blunt and say that all of the pain you see is by design. It's not designed to be a super inclusive or friendly community for contributions. There are explicit gatekeeping checks in place to ensure everyone follows "the Debian way" (nevermind that there is no clear definition of "the Debian way" that anyone agrees on and it's only used to enforce power hierarchies in the project). It comes from an even older gatekeeping around "the Unix way". IMHO ignore all that rubbish.
  - cglong 6y ago
    It sounds like the focus on "the Debian way" is the cause for the symptom cataloged by the original article. The Homebrew maintainers are also notoriously picky (and for good reason), but I think it's the open nature of GitHub that has helped it grow so well. I wonder if opening the Debian gates a bit (at least superficially) would help encourage a healthier package ecosystem.
    - qbasic_forever 6y ago
      Like most things in software, it's ultimately just people and collaboration problems. I should be careful not to paint Debian in too bad of a light because ultimately it's what the people involved make it--good or bad. It's just that historically Debian enthusiasts have gravitated towards a lot of bad, old gatekeeping mindsets that have really made it difficult for the broader Linux community to grow. For example I think back to all the drama with the early days of Ubuntu and how many in the Debian community were vehemently against the idea that someone make a distro that's easier for people to use.
TwoNineFive 6y ago
Sadly in recent years I've seen a number of neglected Debian packages picked up by people who just wanted to pad their resume and say "I'm a Debian maintainer!". This usually has ended badly with the new maintainer not caring about the userbase. They close all open bugs without having fixed anything, and break shit wholesale just so they can say it builds. Please don't pick up a package just because you think it would be cool to be a maintainer. If you are not invested in the well-being of the userbase, you will get called out.
- rrdharan 6y ago
  > If you are not invested in the well-being of the userbase, you will get called out. The person doing this might get called out, but will the negative consequences of that calling out outweigh the resume padding benefit they experience? If not, then I would expect this to keep happening.
ogig 6y ago
At page 3 there is apache2 with more than 300k installs. The maintainer stated no more interest[1]. This seems like low hanging fruit for a massive supply chain attack. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910917 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910917
- iso8859-1 6y ago
  That discussion is probably no longer relevant, because you can see on Salsa that people are pushing patches to the packaging: https://salsa.debian.org/apache-team/apache2 https://salsa.debian.org/apache-team/apache2
- vbernat 6y ago
  The thread shows how supply chain attacks are difficult with Debian: random people cannot really contribute to something like Apache 2 because they need to be sponsored by a Debian developer and they are being asked to do "boring" stuff before that, like triaging bugs and fixing them. The RFH is mostly here to get more people involved, by the maintenance of Apache2 in Debian is going well and the latest version is currently packaged: https://tracker.debian.org/pkg/apache2 https://tracker.debian.org/pkg/apache2.
ncmncm 6y ago
From a quick scan of just the first half, it looks to me like libzstd1 might be the most deserving of help. But I could see libreoffice there.
tluyben2 6y ago
When you click on random (or not so random) packages like Libreoffice, it brings you to [0] where help was requested in 2007 and as recent as oct 2020 offers for help are ignored. Not sure how this 'process' works? [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419523 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419523
- rstuart4133 6y ago
  I'm a Debian developer. It can look a little chaotic from outside. But there are a few simple principles operating here. Mostly they follow from the Debian being a collection of 1000 developers, all equal. There is no CEO who can decide what's important and force someone to do something. Instead, Debian is a do'ocracy. If there is a dispute, it always takes the form of two Debian developers wanting to do something different. (This means users don't get a say. Not because Debian doesn't care, but because it's a do'ocracy and users can't do anything without going through the lengthy test and evaluation process that Debian insists all it's developers must go through.) Asking for help, then not taking up an offer breaks this first rule. We don't have two Debian developers doing conflicting things, so there is no conflict. It may not be the nicest way to behave, but shrug no one can force someone to do something like supervise a newbie. After all Debian developers are unpaid volunteers, and you can't force an unpaid volunteer to do something. Lets take it further. Lets say we have two Debian developers proposing to do different things. Lets say a Debian developer wants to upload a new version of libreoffice. A second rule comes into play here: the package maintainer is king of his packages. He can resist just about anything providing he isn't breaking any policies. So providing the libreoffice package is in reasonably good condition - not too old, all CVE's fixed, yada yada he can resist the new version. In fact I've resisted people wanting to update my package to a beta release, so I've don't just that. Now lets say Debian packager of libreoffice has let it languish, in fact languished so much it's accumulating CVE's. And worse, in order to resist he must be actively deleting the new version. So we have two people doing different things, and they conflict. At this point either developer can invoke Debian's dispute resolution mechanisms. Interestingly the team doing the dispute resolution isn't allowed to do something themselves, they can only chose which (or perhaps neither) of the things done can proceed. In this case not updating a package accumulating CVE's breaks policy, so they would probably allow the developer uploading the new version to proceed. This is a very different way of going about getting work done then people normally experience in their working life. A work environment is typically far more hierarchical and authoritarian. A boss can actually order someone to accept help for example :). However, Debian's system is demonstratedly every bit good as RedHat's. Security patches come out just a quickly, and it has far more packages. And clearly as there are 1000 of us developers all pulling together, it can't be too hard a system to work in.
BiteCode_dev 6y ago
Packaging for debian anything non trivial is damn too hard. It took me 5 days to figure out how to package a complete web app with params, upgrades, post install transpiling, db init, etc. And I haven't put that on a private repo yet, it's yet another annoying thing to do. Nothing is well documented, doc is old and confusing, the tooling is archaic and wants to inflict pain (debconf anyone ?), the life cycle of a Deb package is atrocious to get right. And you have to do all that in raw bash scripts. Not there are no alternatives, any scripting language is potentially usable, but the support is poor enough to deter you from them. It's not I don't want to contribute to the ecosystem, but I won't invest the colossal effort and exercice in frustration to overcome the barrier to entry. My packages don't even need to go to the official repo, just let me do my things in peace. Make a python lib that let you describe a package, hook on life cycle events to run code, with clear documented recipes et where to put what types of files, and let me run that to generate the Deb. Event web pack is easier to use for God sake. I'm not even touching the process of packaging something to be included in debian repositories here, which is another beat entirely. Quit the smug act, debian packagers. You don't know better. You do know better on how to design a distro and protect the official repository. Great. I praised you for that for decades. But you know nothing about making your users life easy. You just don't. So ask them, and fix that, or don't complain about no contrib. This is not news, we raised our voices for years. I contribute all the time to Foss in code and doc, I donate in mass. We ARE willing to help. And we do. It's not us. It's you.
- glandium 6y ago
  > And you have to do all that in raw bash scripts. If only that were true. The entrypoint in Debian packaging is a damn Makefile. I've been a Debian Developer for 16 years, and creating packages for more than that. Saying that I like it or that there aren't problems would be the archetype of Stockholm Syndrome.
- secondcoming 6y ago
  I had to create a custom package of some C++ header files. I failed. I was shocked at how hard it was.
  - 6y ago

201 points by spyc 6y ago

jrwr 6y ago

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

pengaru 6y ago
Neither of those are listed as O(rphaned), they're RFA/RFH.
kwk1 6y ago
Re: sudo, not exactly: https://lists.debian.org/debian-devel/2021/02/msg00234.html https://lists.debian.org/debian-devel/2021/02/msg00234.html
soneil 6y ago
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.)

symlinkk 6y ago

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?

ISL 6y ago
Seems like those Fortune 500 companies might think about making a donation or two?
markstos 6y ago
If you aren't volunteering, don't be surprised that other people aren't either.
- edu-ap 6y ago
  Asuming that only self-funded individuals can contribute in their spare time, but companies can dedicate staff too.
- ducktective 6y ago
  fair...then people shouldn't advertise debian as the most "stable" distro fwiw
  - deleted 6y ago
    [deleted]

janvdberg 6y ago

If you sort by Installs this is kind of disturbing. A lot of well known packages (Apache2 / OpenSSL / LibreOffice etc.) have no owner? https://wnpp.debian.net/?sort=installs%2Fdesc&page=1 https://wnpp.debian.net/?sort=installs%2Fdesc&page=1

amarshall 6y ago
I think packages listed as “RFH” aren’t unmaintained really, just requesting for help maintaining it. Clicking-through on e.g. grub2 shows a mailing list thread requesting for help from…2004. grub2 has certainly received updates in Debian since then.
spyc 6y ago
Column "owner" is the owner of the related issue (bug tracker ticket), not the owner of the package.
blihp 6y ago
Maintainers come and go over time and these things don't just package themselves.
qpiox 6y ago
I think the list of packages that need lovin', needs lovin' itself. It seems this list is abandonware. If you look into the details for some these packages, you will see that it is a dead discussion forgotten even by the person who initiated it, a decade ago. E.g. the discussion about Libreoffice is not about Libreoffice at all, but Apache Open Office, and you can see that there are people who have offered help, but the OP never responded to their offers. Just click on the links on the package names and read for yourself.
- wyclif 6y ago
  When I looked at the list, my first thought was amazement that LibreOffice has no maintainer. EDIT: Previous HN discussion about LibreOffice's lack of resources: https://news.ycombinator.com/item?id=23793942 https://news.ycombinator.com/item?id=23793942
6y ago

pvsnp 6y ago

Aren’t canonical and other distributions upstreaming changes to Debian?

tacostakohashi 6y ago

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://lwn.net/Articles/842319/ https://lwn.net/Articles/842319/ Meanwhile, more and more software is actively hostile to packaging / distributions, and things seem to have devolved into grabbing things from random github repos, or various dedicated/language-specific package managers like npm, pip, brew, ... It's definitely annoying, seems like a step backwards, and its not clear to me whether there's some better distro i could be using, whether some funding / volunteer time could help, or the world has just "moved on" (backwards...) from the idea of a linux distribution with reasonably stable, up-to-date packages that "just work" for basic infrastructure so you can spend your time developing on your own project, instead of with the tedium of fetching and installing software and managing version compatibility problems yourself.

markstos 6y ago
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&arch=any&keywords=rofi-&searchon=names https://packages.ubuntu.com/search?suite=groovy&section=all&... https://aur.archlinux.org/packages/?O=0&SeB=n&K=rofi-&outdated=&SB=n&SO=a&PP=50&do_Search=Go 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.
- Quekid5 6y ago
  > After using Ubuntu for over a decade, I switched to Arch Linux. Hah! Very similar experience; see my sibling reply :)

gigel82 6y ago

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?

spyc 6y ago
Column "owner" is the owner of the related issue (bug tracker ticket), not the owner of the package.

IgorPartola 6y ago

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.

koolba 6y ago
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”.
- IgorPartola 6y ago
  I find that using it on the server is super nice. If you are using Ubuntu on the server anyways, why bother packaging a Docker service for anything else?
dimator 6y ago
What do you recommend for learning that stuff?
- IgorPartola 6y ago
  I wish I could recommend something but I learned it years ago and I honestly don’t remember where from. I’ll try to put together a modern version of my old LUG talk on the subject to show people how to get started.
  - ivan_ah 6y ago
    Yes plz. I'd be very interested to read about this (long time Debian user, but never packaged anything). I know there is an install, postinstall, and remove scripts but don't have a clear idea of when exactly they will get called and what "interface" they must implement. It would be really helpful to have a "package lifecycle" state diagram like this https://vuejs.org/v2/guide/instance.html#Lifecycle-Diagram https://vuejs.org/v2/guide/instance.html#Lifecycle-Diagram that shows all the states and events that "fire" based on .deb scripts and metadata.

kenniskrag 6y ago

why is eclipse so many version behind the current version? I do not think it would hurt to update a little faster.

vore 6y ago
If there's no people volunteering to update it, then there's nobody to update it a little faster.
qpiox 6y ago
Why would you need a package for Eclipse. Download it is a ZIP, extract it in the location of your choice and run it from there. (Portable app) I have been using it like that almost every day for 15 years now.
- rjsw 6y ago
  Eclipse isn't portable, somebody has to compile it for Linux, it just comes down to whether you want that done by the Eclipse Foundation or Debian people.
  - qpiox 6y ago
    The discussion here was about why a debian package for Eclipse is not up to date. My theory is that it is obviously because there is a way how to run Eclipse, without any issues and without the need of an officially tested debian package, so there is not huge demand.
    - rjsw 6y ago
      That would be fine if Linux preserved backwards compatibility, the glibc version change last year meant that some binary packages no longer run. Something like Netbeans doesn't need a debian package but Eclipse is split into lots of jar files that each depends on some shared libraries.
yjftsjthsd-h 6y ago
Okay, so why don't you volunteer to update it?

oneweekwonder 6y ago

Linux Standard Base recommend rpm support. But the rpm package need adoption and refers users to alien, but the alien package is orphaned. hah, looking at wikpedia it seems LSB support have been dropped by Ubuntu and Debian in November 2015.

slavik81 6y ago

If I want to help, what should I do?

qpiox 6y ago
Well, you need to get competent enough before you take on a role as package maintainer. For start, imagine that you are one. First, choose a package that really matters to you. On a daily basis. A package that you yourself would NEED to have it up2date the next day a new version is out. Get the source deb and try to build it. Usually it's not very hard. Then, try to do the same on all the debian variants (unstable, stable, ...) If you succeed and the package works, you have the prerequisite competencies, at least as a beginner. Then, these are some of the things that you will need to do, quite often. Change the configuration of the package description so that you can build it with a later version of the source. For all variants of the distro. Then try the same with the package dependencies, where those dependecies are not needed for other packages. Then try to push it as close towards the latest source version, as you can without breaking stuff. Once you do all that without issues and you are confident that you can use the version you built from source as a daily driver and you are not bothered by that, contact the original maintainer directly and offer help, sharing the details what you did as proof that you are competent enough. If the maintainer is uncollaborative or unresponsive, put up your own repo for public use, and invite the public to install the package from your repo, so that the public will see some benefit and you will receive zillion of bug reports to further streghten your competence level.
- deleted 6y ago
  [deleted]
- slavik81 6y ago
  That does seem like it would be a sensible way of going about things if I could manage to find a package of modest complexity that is important to me, but under-maintained.
  - qpiox 6y ago
    Maintaining a package is not as hard as developing software. You don't need to know algorithms, you don't need to know programming, you just need to know how to start a compiler and packaging software from the command line and read errors from the log. If you are an active developer in the language that is used it will be easier, but you can do it even if you are not. Example. Todays news here, is the latest release of Kodi. Debian does not have the most recent version. Some months ago I had an issue with the Kodi from the debian multimedia repo, so I decided to build it from source. It took me the better part of a day to have all the build tools installed and set-up everything, starting from zero. But in the end I had the latest Kodi running and it was running like that for 5 months and I even forget that I built it. I managed to do that without even looking into the source code. In fact if you ask me what programming language is used to develop Kodi - I really don't know and don't remember. Package maintainance is more about testing than about building. So a list like this can serve as a guide in the process of choosing where to help. Just sort by number of users that use the software and go down the list until you find something that you use daily and where you would like to have the most recent version available and would volunteer your effort for 2-3 years (it is not really helpful if maintainers change every couple of months).

noobermin 6y ago

This 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 is become more and more bare as the years go on. For example, I miss eix whenever I use debian, apt-cache just isn't as useful. Also, having to use not systemd is a plus and a reason I won't use Arch. Any suggestions?

LanternLight83 6y ago
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 projects resources.
- LanternLight83 6y ago
  Gentoo packages, by virtue of use flags, do seem like they'd take more effort to build and maintain, but I don't know enough about gentoo packaging as I'd like to :p
  - spyc 6y ago
    I have packaged for both Debian and Gentoo; packaging for Gentoo is way easier and more fun, one reason being that (simplified) you're dealing with a single Bash file rather than a magic Makefile and things split into 20+ small files. The difference is huge.
- noobermin 6y ago
  The thing I'm imagining is that if there was something I wanted the USE flags for, I'd just end up compiling myself in a prefix. I already do this for some packages because of the issue with Gentoo removing things they consider stale which is the problem. I don't need USE flags all the time or compiling everything with -O3 -march or whatever, for most things it's just a plus that it might be faster. I think the one thing that might actually matter for me is in Gentoo fixing broken things is more direct, just compile, while I've had issues that persist on ubuntu even after reinstalling something. It just felt like there was somehow "stale state" in my OS which even sounds ridiculous saying. But, at this point, I can't handle breaks in portage because while you can fix things, it requires mental effort on my part and I'm tired of it. EDIT: reading your comment, if you're asking for my opinion I mean look at this in particular: https://bugs.gentoo.org/420783 https://bugs.gentoo.org/420783 ioquake3 was literally removed from portage for this "bug" which even if you accept that it's a hypothetical issue has easy patches that were never included, and it was removed, essentially removing hosts of open source fpses from portage! I even read a forum post talking about "upstream" not caring...upstream? ioquake3's release was charity, it's not like an active project. This has been happening for a while. I've been here since 2008 or so and the instability and removal of slots within months has gotten out of hand. Again, the tooling is great, emerge, eix, the whole system of configuration files is awesome and I'm just used to openrc. I wish I could keep them but the slot removals in portage has just become such a chore to deal with.

jonathankoren 6y ago

Looking at orphans by installs and I remember using some of these 20 years ago, but do people even use libgpod and xmms anymore?

notatoad 6y ago
that's my first reaction to this list too - is a debian-specific package really providing more value than the effort of maintaining it for a lot of this software? even libgpod and xmms are relatively high-profile examples. i do appreciate being able to apt-get install some obscure package and have often wondered how it's a sustainable system that maintainers are putting in effort to package these things up into a distro for me. but maybe it isn't?
- jonathankoren 6y ago
  I wonder if the install base is is so high because 20 years ago some package maintainer decided to put XMMS in a gnome-apps (or whatever) metapackage, and no one removed it. I don’t even know the last time I found a publicly accessible mp3 url stream, or listened to a local mp3 file. Local files had to be like 10 years ago.

crb002 6y ago

Resorted by installs https://wnpp.debian.net/?page=1&sort=installs%2Fdesc https://wnpp.debian.net/?page=1&sort=installs%2Fdesc

spyc 6y ago
You have a point here: I have made that^^ the new default sort order now.

cglong 6y ago

As someone who's thinking about moving to Linux and has made many non-trivial contributions to Homebrew, the contribution process for Debian packages scares me. The official documentation seems to be more of a reference guide than a tutorial, and community blog posts always seem to start with "That other tool is outdated; here's the new way to do it," making it impossible to know which method is the right one. IMO, what really needs some lovin' is the official onboarding process for new contributors.

qbasic_forever 6y ago
Here's something to keep in mind that isn't super clear to newcomers, Linux != Debian. Linus Torvalds doesn't use Debian and nothing Debian does really impacts him or the core of Linux. Debian is just a highly opinionated take on Linux. You can totally dive in and be super productive with Linux without ever having to know about, use or, or care that Debian exists. (oh and Homebrew works great on Linux, give it a shot as it's a really easy way to move over from OSX). Regarding the Debian package process, etc.--I'll be blunt and say that all of the pain you see is by design. It's not designed to be a super inclusive or friendly community for contributions. There are explicit gatekeeping checks in place to ensure everyone follows "the Debian way" (nevermind that there is no clear definition of "the Debian way" that anyone agrees on and it's only used to enforce power hierarchies in the project). It comes from an even older gatekeeping around "the Unix way". IMHO ignore all that rubbish.
- cglong 6y ago
  It sounds like the focus on "the Debian way" is the cause for the symptom cataloged by the original article. The Homebrew maintainers are also notoriously picky (and for good reason), but I think it's the open nature of GitHub that has helped it grow so well. I wonder if opening the Debian gates a bit (at least superficially) would help encourage a healthier package ecosystem.
  - qbasic_forever 6y ago
    Like most things in software, it's ultimately just people and collaboration problems. I should be careful not to paint Debian in too bad of a light because ultimately it's what the people involved make it--good or bad. It's just that historically Debian enthusiasts have gravitated towards a lot of bad, old gatekeeping mindsets that have really made it difficult for the broader Linux community to grow. For example I think back to all the drama with the early days of Ubuntu and how many in the Debian community were vehemently against the idea that someone make a distro that's easier for people to use.

TwoNineFive 6y ago

Sadly in recent years I've seen a number of neglected Debian packages picked up by people who just wanted to pad their resume and say "I'm a Debian maintainer!". This usually has ended badly with the new maintainer not caring about the userbase. They close all open bugs without having fixed anything, and break shit wholesale just so they can say it builds. Please don't pick up a package just because you think it would be cool to be a maintainer. If you are not invested in the well-being of the userbase, you will get called out.

rrdharan 6y ago
> If you are not invested in the well-being of the userbase, you will get called out. The person doing this might get called out, but will the negative consequences of that calling out outweigh the resume padding benefit they experience? If not, then I would expect this to keep happening.

ogig 6y ago

At page 3 there is apache2 with more than 300k installs. The maintainer stated no more interest[1]. This seems like low hanging fruit for a massive supply chain attack. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910917 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910917

iso8859-1 6y ago
That discussion is probably no longer relevant, because you can see on Salsa that people are pushing patches to the packaging: https://salsa.debian.org/apache-team/apache2 https://salsa.debian.org/apache-team/apache2
vbernat 6y ago
The thread shows how supply chain attacks are difficult with Debian: random people cannot really contribute to something like Apache 2 because they need to be sponsored by a Debian developer and they are being asked to do "boring" stuff before that, like triaging bugs and fixing them. The RFH is mostly here to get more people involved, by the maintenance of Apache2 in Debian is going well and the latest version is currently packaged: https://tracker.debian.org/pkg/apache2 https://tracker.debian.org/pkg/apache2.

ncmncm 6y ago

From a quick scan of just the first half, it looks to me like libzstd1 might be the most deserving of help. But I could see libreoffice there.

tluyben2 6y ago

When you click on random (or not so random) packages like Libreoffice, it brings you to [0] where help was requested in 2007 and as recent as oct 2020 offers for help are ignored. Not sure how this 'process' works? [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419523 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419523

rstuart4133 6y ago
I'm a Debian developer. It can look a little chaotic from outside. But there are a few simple principles operating here. Mostly they follow from the Debian being a collection of 1000 developers, all equal. There is no CEO who can decide what's important and force someone to do something. Instead, Debian is a do'ocracy. If there is a dispute, it always takes the form of two Debian developers wanting to do something different. (This means users don't get a say. Not because Debian doesn't care, but because it's a do'ocracy and users can't do anything without going through the lengthy test and evaluation process that Debian insists all it's developers must go through.) Asking for help, then not taking up an offer breaks this first rule. We don't have two Debian developers doing conflicting things, so there is no conflict. It may not be the nicest way to behave, but shrug no one can force someone to do something like supervise a newbie. After all Debian developers are unpaid volunteers, and you can't force an unpaid volunteer to do something. Lets take it further. Lets say we have two Debian developers proposing to do different things. Lets say a Debian developer wants to upload a new version of libreoffice. A second rule comes into play here: the package maintainer is king of his packages. He can resist just about anything providing he isn't breaking any policies. So providing the libreoffice package is in reasonably good condition - not too old, all CVE's fixed, yada yada he can resist the new version. In fact I've resisted people wanting to update my package to a beta release, so I've don't just that. Now lets say Debian packager of libreoffice has let it languish, in fact languished so much it's accumulating CVE's. And worse, in order to resist he must be actively deleting the new version. So we have two people doing different things, and they conflict. At this point either developer can invoke Debian's dispute resolution mechanisms. Interestingly the team doing the dispute resolution isn't allowed to do something themselves, they can only chose which (or perhaps neither) of the things done can proceed. In this case not updating a package accumulating CVE's breaks policy, so they would probably allow the developer uploading the new version to proceed. This is a very different way of going about getting work done then people normally experience in their working life. A work environment is typically far more hierarchical and authoritarian. A boss can actually order someone to accept help for example :). However, Debian's system is demonstratedly every bit good as RedHat's. Security patches come out just a quickly, and it has far more packages. And clearly as there are 1000 of us developers all pulling together, it can't be too hard a system to work in.

BiteCode_dev 6y ago

Packaging for debian anything non trivial is damn too hard. It took me 5 days to figure out how to package a complete web app with params, upgrades, post install transpiling, db init, etc. And I haven't put that on a private repo yet, it's yet another annoying thing to do. Nothing is well documented, doc is old and confusing, the tooling is archaic and wants to inflict pain (debconf anyone ?), the life cycle of a Deb package is atrocious to get right. And you have to do all that in raw bash scripts. Not there are no alternatives, any scripting language is potentially usable, but the support is poor enough to deter you from them. It's not I don't want to contribute to the ecosystem, but I won't invest the colossal effort and exercice in frustration to overcome the barrier to entry. My packages don't even need to go to the official repo, just let me do my things in peace. Make a python lib that let you describe a package, hook on life cycle events to run code, with clear documented recipes et where to put what types of files, and let me run that to generate the Deb. Event web pack is easier to use for God sake. I'm not even touching the process of packaging something to be included in debian repositories here, which is another beat entirely. Quit the smug act, debian packagers. You don't know better. You do know better on how to design a distro and protect the official repository. Great. I praised you for that for decades. But you know nothing about making your users life easy. You just don't. So ask them, and fix that, or don't complain about no contrib. This is not news, we raised our voices for years. I contribute all the time to Foss in code and doc, I donate in mass. We ARE willing to help. And we do. It's not us. It's you.

glandium 6y ago
> And you have to do all that in raw bash scripts. If only that were true. The entrypoint in Debian packaging is a damn Makefile. I've been a Debian Developer for 16 years, and creating packages for more than that. Saying that I like it or that there aren't problems would be the archetype of Stockholm Syndrome.
secondcoming 6y ago
I had to create a custom package of some C++ header files. I failed. I was shocked at how hard it was.
- 6y ago