Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The git annex developer is more pessimistic about the future of Debian: https://joeyh.name/blog/entry/futures_of_distributions/


The Debian processes of package authoring is very complex. I maintain my selection of packages as a private metapackage so that I can "sudo apt-get install ./goktug.deb" and be ready, basically just a list of packages, and even that's complex compared to a PKGBUILD or a BSD port. Recently I wanted to package and maintain Arch Linux's netctl for Debian, and reading the suggested documentation, multiple hours in, having accumulated dozens of tabs of highly-suggested or required reading, I realised I still didn't have a working example package at my hands, and gave up. Furthermore, my packages list had to grow up incorporating more than ten tools specific to making and maintaining Debian packages, before I had even a working prototype of the thing at hand. I'd prefer by far making an RPM or pacman package to that.

Edit: After reading the linked article, I want to add this: I believe things from NPM don't really need to be packaged individually. The community is an outlier in many respects, with its sloppy practices, its very wide scope and the sheer innumerable amount of "packages" it hosts (many hundreds of thousands). For the rest, only the libraries the application software packages (from Firefox to coreutils, anything that's not a library) use need to be packaged. The rest is most often installed by developers or users that are installing non-package software, so they will somehow need to use a third party package manager anyways. The OS package manager does not need to include everything, but what's essential and stable.


It doesn't help that many of the official Debian wiki pages contradict eachother in what tools to use or how to use them. It took me a long time of plain experimentation to realize that the debian directory contents are mostly agnostic to what tools you're using to build the package itself, and then it's just figuring out which CLI build tools you can figure out how to get to run (for me it was a combination of cowbuilder + pdebuild, and cowbuilder is optional).


If you use that metapackage just for installing a list of things you keep as a base system, it may be easier to just keep a list of selections. dpkg --get-selections to get the list, and then to reinstall:

    dpkg --set-selections
    apt-get dselect-upgrade


Thanks for the tip! Indeed that's how I use it (see [1]), I want a manually curated list of packages that compose my base system (the packages that I explicitly want installed, not all packages and their dependencies). If using this I can skip the metapackage, that'd be an improvement, will look into it.

[1] https://github.com/cadadr/configuration/tree/master/deb/DEBI...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: