I don't mean to stir up trouble so don't take my comment offensively or anything - but every time I see debian packaging being talked about reminds me how thankful I should be to only have to deal with Arch packages.

The Debian packaging pipeline is really insanely complex. Arch packaging barely needs a tutorial at all. The best part about it is how all the packaging tools are shipped with the package manager. pacman can install remote packages as well as tarballs, and "makepkg" ships with pacman.

Scratch that actually - the best part about it is how development libraries ship alongside the packages. I really don't miss having to install -dev packages all the time, especially having hundreds of them polluting all my queries.

When I tried creating packages for debian (this was quite a way back and it seems like things have improved, but not that much), I spent ages getting all the packages I needed in the first place and I had to keep track of far too many commands, had to constantly re-open the tutorials every time I wanted to create a new one. The PPA system is also far too cumbersome for one-off packages you want to distribute, compared to distributing just a PKGBUILD / source package (especially since arch has the AUR).

I feel the debian world could really stand to take some lessons from Arch in that aspect.

There is a big difference in quality of packages. Debian primary focus is stability, security, upgrading from 5 years old package to newest, strict freedom.

You can build Debian packages as Arch but that wouldn't be the Debian way.

Stability - our QA process is huge and much more strict then the Arch one. We often notice upstream bugs during our packaging and testing process and we also often patch them before upstream.

Security - we have Debian Security Team which is ruthless and security is a big focus so when for example the Chromium security problems was found, it was also noticed that that feature was disabled in Debian chromium package by default.

Upgrading - I don't think any distro can offer this without issues and those issues are exactly prevented with out packaging guides and Debian Policy. In Arch you would get from time to time - please do this manual things in order to upgrade to next version of this software. While in Debian you can go to trip to Mars, live there for few years, come back and then just apt update && apt dist-upgrade the thing and go on coffee without worry.

Also notice we had much before Arch the gpg signing of packages, you can't become Debian maintainer without at least two Debian Developer signatures on your key which happen in face-to-face meetings (so we create a web of trust you will not introduce bad code in your packaging).

So yes, you are correct that easier is to create Arch package then Debian official one, but in Debian you can also create very quickly packages (checkinstall, fpm etc etc) but then you miss all the power of Debian and you're on your own with those packages and potential breakage with system (or is that a freedom you have?) :)

You are conflating curation/QA and packaging. Packaging itself should not care about the quality of the packages.

It's well known that the debian repositories are extremely well reviewed and tested. But you could have that with Arch's packaging system as well.

When someone builds a package themselves however, they are not expecting Debian's QA & testing nor are they usually interested in it. But a package, untested as it may be, is far, far better than a sudo make install.

When I used debian this was such a huge pain. Building packages was not worth the hassle so I would simply sudo make install and feel awful about it, and end up with conflicts and everything that a package manager is supposed to solve...

You see, there is where you mistake. Debian official packaging is about Quality of package. Lintian checks for example is your library really a library or it maybe contains scripts, did you make a mistake in description (simple letter mistake), did you miss new copyright files (or change in copyright of the same). There is also a reason why it suggests building in clean chroots, installation in same clean environment. You also have piuparts to check it's transition. Debian packaging is a huge thing and it would take me quite a time to explain it and I would still miss something. Also our packaging assumes that not all upstreams make sane coding or installation scripts so we detect them before just pushing them into system.

As you said, Arch could have all that but it doesn't and there are the reason why people who use Debian don't use Arch. Again, you can quickly make deb packages without following any of our docs and no, package manager should not solve what differs from our official build quality and Debian Policy (it would be too much hassle to predict and implement in how many ways people can break their system).

I am glad that Arch exists, so everyone has a freedom to choose it if they want :)

Arch does have a lot of that. Not all of it, but it does have clean chroot building, gpg signing, linting etc. Mostly, arch does less testing as the philosophy is "trust upstream".

However, none of this is required for unofficial packages. You can do it, but you don't have to. This is where I'm saying you're conflating two different things - QA and packaging are separate.

Please don't get me wrong, I love debian and they do an incredible service to the Linux community with their testing. But why force it all on users that just want to build a simple package instead of doing make install as root?

Again, QA is part of Debian packaging (just check all the debian lintian checks https://lintian.debian.org/tags-all.html - and you do officially run lintian on your packages).

Again, no one is forcing you to do official Debian packaging if you want to create simple deb for your purposes and it was mentioned in this thread by other and me several times (and several tools).

If on the other hand your goal is not to get a package in Debian, but only to quickly make a deb file, check out fpm: https://github.com/jordansissel/fpm.

Yep, the tutorial name should be how to quickly (low quality) create a deb package from simple source. :)

Also you can use equivs for creating quick (dummy?) packages :D

The link to other resources and the expertise expressed in the head comment of this thread was helpful. The insults are not.

what insults?

As a Debian user, it's a fine tutorial. Not every .deb is built for distribution with Debian itself. The only change I'd make is to clarify that what's being built here is a "for personal use only" package.

As to the debian.org guides, I've always found them obtuse precisely because they emphasise what you've got to do to get a package distributed, rather than the plain technical details of how they work.

Packaging tutorial shouldn't be technical details how deb package works but how you build one (if you want those details you can also find them in Debian documentation but in the end deb package is just an ar file with it's set of make file that satisfies the installation in specific distro - this is the simple explanation). And no, the tutorial is misleading because Debian packaging means doing it for Debian, while creating a deb package for your personal need is different. You also have Ubuntu packaging guides and so on.

But the guides aren't just how you build a package. They're how you package something for official distribution. The requirements for the former aren't nearly as stringent as for the latter, and by obscuring the former behind the latter, Debian makes its packaging guides less useful.

Debian packaging guides are less useful because they concentrate on how to build package for Debian?

And nobody is hiding from you any tutorial - Debian is an open community and the wiki is open to everyone so you can search for what you need but I really don't see the point in your sentences (are you saying that we should favorite somehow quick and dirty hacks instead of our strict high-quality ways of building packages? Because if yes, then Debian wouldn't be what it is today...)

Yes, that's exactly correct. Debian's tutorials are less generally useful because, to serve the specific goal of keeping Debian's packages high quality, they obscure what you can do behind what Debian thinks you should.

First of all (repeating myself again): there is a lot of documentation out there (already mentioned multiple times in this thread) how you can build debs quickly. Also, Debian tutorials are Debian tutorials and they should serve Debian primarily and not some third-party, but still you have all documentation on Debian wiki (and also manpages of specific packages) - you just need to do a bit of search.

Second: saying that Debian's tutorials are less useful because they have specific goal of high quality - makes me really sad. Debian is community and not corporation, so to see that community has higher standard then any corporation should be praised. Also Debian's packaging evolved over 20+ years by thousands of hackers (experts in their field) all over world in their unique collaboration. I am sure this should be taken as a pride that you can go on net an read such tutorials.

And really, if someone thinks he is technical but can't read few pages of not so demanding tutorial, then problem is in them because in software world you evolve every day and need to read and code a lot to keep a pace. Only problem that you could say is that maybe isn't that fun to read (because Debian wikis are old school so the sentences stretch through entire screen while today's web is focused on centering all which makes it a bit easy to read and so on).

That's the motivation behind writing this. I've edited to include that this is for personal use only. I've found debian.org guides difficult to read as well. Thanks for the feedback!

Those are definitely better links, but a while back I needed a quick guide to make something that worked on private servers. I couldn't find a quickstart guide, so I decided to make one. Thanks for the feedback!

You really should take more care of servers :)

What does Debian miss that you need for your servers (I am really interested).

Also for quick and dirty you could use checkinstall.

There is also a good tutorial on DigitalOcean about fpm:

https://www.digitalocean.com/community/tutorials/how-to-use-...

And just maybe me nitpicking too much but the title should be then "How to quickly create deb package for personal needs". Notice that this means you don't get Debian Security support for your own package so that can be a huge breaker for many people running servers :)

I wasn't aware of the DigitalOcean tutorials and the tutorials on debian.org (at least the ones I saw) were pretty dense. I wanted to just package it up and get it running within a few hours (quick dirty install as you said) and couldn't use anything else due to external constraints.

I agree with the modified title suggestion and have changed the title of my blog post.

Thanks for your feedback! :)

You welcome and thanks for taking suggestions into account.

For simple things you probably want to use in future more of checkinstall (to keep it easier for yourself the creation, installation and removal part):

https://wiki.debian.org/CheckInstall

CheckInstall looks nice! I'll definitely take it into account next time I need a quick package done. I've also added it to my post. Thanks!