Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian Packages That Need Lovin'

wnpp.debian.net

Post reply on HN
Print view View original

121–130 of 151 posts

Re: Debian Packages That Need Lovin'

#121

Post by neilwilson »

raverbashing wrote: post #118
BiteCode_dev wrote: post #101

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…

I'll put it like this: Debian bureaucracy makes your usual governmental bureaucracy seems sane and sensible in comparison No accountability, tightly knit cabal with high barrier to entry, refractory to external opinions, etc

Yes. It’s a living breathing example of how Anarchy operates.

Which was the intention I believe - hence why https://packages.debian.org/stable/doc/anarchism is a package.

Re: Debian Packages That Need Lovin'

#122

Post by Quekid5 »

nanna wrote: post #96
Quekid5 wrote: post #18

Earlier quoted context omitted.

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-compi…

It doesn't have to be one or the other. I've been very happily using Guix as a package manager inside my Debian, thereby having a Debian with up-to-date versions of packages and access to all the other benefits of using a next-generation package manager (specifying release candidates, docker-like portable builds, plus emacs integration). Just have to be slightly careful not to install packages via Guix that might cau…

I have done this as well (with Nix rather than Guix, but it doesn't matter). You do run into some friction sometimes, e.g. the UI themes from your main distro not applying properly (because paths are all wrong).

It does basically work, but it can be a bit jarring, depending on exactly what you're trying to do.

Re: Debian Packages That Need Lovin'

#124

Post by Fronzie »

secondcoming wrote: post #111
BiteCode_dev wrote: post #101

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…

I had to create a custom package of some C++ header files. I failed. I was shocked at how hard it was.

For my (local) C++ projects, I use CMake to make .deb packages. It is easy enough, uninstalls cleanly, so does the job.

Re: Debian Packages That Need Lovin'

#125

Post by laykg »

BiteCode_dev wrote: post #101

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…

I think many package managers take longer than a week to figure out. RPM is more difficult that deb, setuptools takes months to understand it fully and is changing constantly.

Meson, Conan, winget+msi, and the hundreds of other mixtures of build system + package manager also take long to understand. And you have to understand each of them.

Homebrew does not even want package authors to create packages themselves.

It may be a matter of perception: If you count all web searches, interactions with CI, conference talks that help you understand a more recent package manager, it will also add up to 5 days.

Creating a deb is more boring, it's just the machine and you.

Re: Debian Packages That Need Lovin'

#126

Post by linkdd »

BiteCode_dev wrote: post #101

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…

Back in the day, I created my packages manually (creating the TAR archives, the preinstall/postinstall scripts, and putting all of that in an AR archive, renaming it to .deb).

I never even read the documentation, I just did:

  $ file some.deb
  $ ar --output somedir some.deb
  $ ls somedir
Definitely not the recommended way, but I never spent more than 10min on a Debian package (installed with dpkg and not through repositories).

Re: Debian Packages That Need Lovin'

#127

Post by spyc »

LanternLight83 wrote: post #64
LanternLight83 wrote: post #63

Earlier quoted context omitted.

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…

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

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.

Re: Debian Packages That Need Lovin'

#128

Post by spyc »

BiteCode_dev wrote: post #101

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…

You have some points here, but the Bash part is _not_ the problem. Bash is everywhere and the true fix to that bit is to learn Bash: It's not hard and I benefit from my Bash skills everyday, it's one of the best things to invest even a bit in. Just don't write "actual software" in Bash.

Re: Debian Packages That Need Lovin'

#129

Post by qpiox »

slavik81 wrote: post #89
qpiox wrote: post #56

Earlier quoted context omitted.

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, s…

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.

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).

Re: Debian Packages That Need Lovin'

#130

Post by iforgotpassword »

m463 wrote: post #42
Quekid5 wrote: post #18

Earlier quoted context omitted.

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-compi…

> 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?

Personally I feel like in many ways OSS got its shit together here over the past decade or so, especially when it comes to default directories and naming conventions etc., so maybe traditional distros might want to reconsider adding so many patches for everything. Its especially bad if it's security patches for unmaintained software, as they are often incomplete, different distros all come up with their own patches whenever someone stumbles upon the bug, because why talk to others and try to prevent duplicate work...
Post reply on HN