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

111–120 of 151 posts

Re: Debian Packages That Need Lovin'

#111

Post by secondcoming »

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.

Re: Debian Packages That Need Lovin'

#112

Post by tuankiet65 »

mixedCase wrote: post #36
metafunctor wrote: post #29

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

> 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 used to believe that a properly configured Arch Linux setup is super stable, until one day when I upgraded the Linux kernel and there was multiple GPU hangs and graphics glitches. It's fixed upstream now, but it does make me think again about running close to the bleeding edge.

On the same line, I don't realize that my Bluetooth driver was broken until I checked dmesg. This one wasn't fixed upstream yet, but I don't need Bluetooth on my laptop anyway.

Re: Debian Packages That Need Lovin'

#113

Post by afiori »

cauthon wrote: post #92
LordDragonfang wrote: post #91

Earlier quoted context omitted.

I understand if you're taking issue with the term as a pejorative, but how is purposefully placing barriers for those that don't conform to the "specifically-defined approach" not definitionally gatekeeping?

I think of "gatekeeping" as blocking access, especially for something that doesn't have a defined membership, like a fandom. e.g. "you're not a real star wars fan if..." whereas anyone is welcome to contribute to debian, they just have to follow the rules. there's kind of no meaning to the term "gatekeeping" if any organization that has rules to follow counts.

gatekeeping is used as pejorative in those cases, where no gate ought to be. for example in at least one email Linus claims that forbidding C++ in the kernel was also to exclude C++ developers, whether he was right or wrong that is another case of gatekeeping

Re: Debian Packages That Need Lovin'

#114

Post by vbernat »

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…

As for building packages for your own use, the tooling is not that difficult. The documentation is just oriented to contribute packages for Debian itself. This implies some unwanted complexity and navigating outdated documentation. Packaging for Debian becomes simpler, but it's heavily rooted into having multiple files describing the package, use of a tarball as the source package and having each language comes with its own helper and documentation.

Here is a "pragmatic" way to write Debian packages without relying on non-Debian tools: https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-pack... (I am the author).

But other than that, I quite agree with your stance: we (Debian) makes life of our contributors harder than it should be. Unfortunately, there is no awareness in the project for that. People trying to change that just silent themselves, like https://michael.stapelberg.ch/posts/2019-03-10-debian-windin....

Re: Debian Packages That Need Lovin'

#115

Post by pjmlp »

ilammy wrote: post #37
tacostakohashi wrote: post #10

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…

> things seem to have devolved into grabbing things from random github repos Devolved from what ? I believe from software not having any dependencies unless they absolutely must because adding dependencies is such a royal pain. Software written in C and C++ has long been used to the system package manager being language package manager, and the (UNIX) OS being its IDE.

A clear example why platform languages always win.

C was born to make UNIX portable, and C++ was born a couple of years later on the same office rooms where UNIX came to life.

Any guest language introduces additional hurdles, debugging tools, binding libraries, editor support, and naturally OS package managers.

Re: Debian Packages That Need Lovin'

#116

Post by pjmlp »

Spooky23 wrote: post #47
ilammy wrote: post #37

Earlier quoted context omitted.

> things seem to have devolved into grabbing things from random github repos Devolved from what ? I believe from software not having any dependencies unless they absolutely must because adding dependencies is such a royal pain. Software written in C and C++ has long been used to the system package manager being language package manager, and the (UNIX) OS being its IDE.

IMO, this moved forward with Linux at the OS level 20 years ago with apt and rpm. Seems like now that hyper scale cloud vendors are displacing distros as gatekeeper, we’re going down a road towards niche packaging for languages, frameworks, etc.

Because for those languages, their runtimes are the platform, the underlying OS is irrelevant, as long as the runtime and associated libraries provide the required abstractions to deliver what is being asked for.

UNIX is C's platform, hence POSIX and its influence on C and C++ based OSes.

Re: Debian Packages That Need Lovin'

#117

Post by vbernat »

cglong wrote: post #70

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

Debian packaging being complex, there are many documentations around it. Packaging practices also change, but it's difficult to know which documentation is up-to-date or not. However, the very official documentation from the project is kept up-to-date: https://www.debian.org/doc/manuals/maint-guide/ and https://www.debian.org/doc/manuals/developers-reference/. But, yes, they are long and only cover the basics. There is also https://www.debian.org/doc/manuals/packaging-tutorial/packag... which is kept up-to-date and is more in the tutorial style.

Every few years, there are various attempts at simplifying packaging, usually in the form of a more universal helper to build a package skeleton, but it doesn't really reduce the complexity and until now, none of these helpers replaced debmake.

Re: Debian Packages That Need Lovin'

#118

Post by raverbashing »

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

Re: Debian Packages That Need Lovin'

#119

Post by qznc »

vbernat wrote: post #114
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…

As for building packages for your own use, the tooling is not that difficult. The documentation is just oriented to contribute packages for Debian itself. This implies some unwanted complexity and navigating outdated documentation. Packaging for Debian becomes simpler, but it's heavily rooted into having multiple files describing the package, use of a tarball as the source package and having each language comes with…

I also made myself a deb packager script in 100 lines: https://github.com/qznc/simpledeb

It doesn't cover anything fancy like post-install actions though.

Re: Debian Packages That Need Lovin'

#120

Post by qznc »

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…

On the other hand, Debian is a large community of volunteers providing a distro on democratic principles for a long time successfully. Comparable distros are either companies (Ubuntu, RedHat, SuSE) or heroic deeds of one or few people (Slackware). I find that an amazing even if it is heavily burdened by technical debt these days.
Post reply on HN