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.
Debian Packages That Need Lovin'
71–80 of 151 posts
Re: Debian Packages That Need Lovin'
#72[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910917
Re: Debian Packages That Need Lovin'
#73Re: Debian Packages That Need Lovin'
#74As 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, w…
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.
Re: Debian Packages That Need Lovin'
#75Earlier quoted context omitted.
What do you recommend for learning that stuff?
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.
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 that shows all the states and events that "fire" based on .deb scripts and metadata.
Re: Debian Packages That Need Lovin'
#76As 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, w…
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…
Re: Debian Packages That Need Lovin'
#77Earlier quoted context omitted.
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…
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.
Re: Debian Packages That Need Lovin'
#78As 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, w…
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…
And I'll offer a defence of that barrier - Debian isn't about making an operating system. It is very explicitly making a free operating system. Listening to one Q&A session after a Stallman speech was more than enough to show me that there are a lot of capable developers out there who just don't get the idea of free. While those developers are a mighty force for good they need to be kept away from the Debian main archive. It isn't a place for them. They can go start their own project (eg: Ubuntu, Mint).
Re: Debian Packages That Need Lovin'
#79Sadly 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 woul…
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.
Re: Debian Packages That Need Lovin'
#80Earlier quoted context omitted.
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 wish there were more standards & conventions here. It seems silly that every package needs to be manually packaged for Debian/red hat/arch/etc, FreeBSD, homebrew, and maybe Cygwin/whatever people use now. That’s a whole lot of work, often for every new version of the program! And all that work could vanish if there was a standard bundler. I think modern package managers for programming languages show us the right a…
The same balance of forces that mandate all of that toilsome work are exactly what would prevent any standard bundler from succeeding.
You can follow https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaks... and https://www.techrepublic.com/article/why-snap-and-flatpak-ar... and various related discussions around this and eventually I am confident you will conclude that while things may change (today there's docker in the mix as well, tomorrow there will be something else), the one-true-packaging-solution will never be invented.
There are simply far too many fundamentally conflicting interests to ever prevent that level of standardization.
What you see now is more or less what you will always get. Or, perhaps, we'll see something worse (i.e. only fully locked down computing devices, only app stores with no sideloading capabilities, various other dystopian outcomes). I'm pretty sure we're not going to see something better though; we've had plenty of time...