3 ms·

Well, to be fair, no package maintainers are touching any of the stuff described here. All the "ar" and "control.tar" stuff is handled for you by the tools. Thi

by dima55 2y ago

Well, to be fair, no package maintainers are touching any of the stuff described here. All the "ar" and "control.tar" stuff is handled for you by the tools. This isn't a "this is how you build packages" article, it's a "here's how the guts of these packages work" article.

kasabali 2y ago
to be really fair, the tools package maintainers use are more complicated than stuff described in the blog post. Best way to discourage anyone from generating a .deb package is recommending him read the official "new maintainers guide"
- dima55 2y ago
  To do the stuff the blog post talks about you 'dpkg-buildpackage'. That's it. After years of maintaining packages, I think I decided that much of the complexity is unfortunately warranted. You want stuff to work in all sorts of situations, with all sorts of different other things installed at the same time. You want upgrades to work. You want tests to work and to run, but probably you want to skip them when cross-building. You want the package to be co-installable across architectures. You want the package to be cross-buildable and to be usable to cross-build other packages. And you want your builds to be reproducible. And lots and lots of other things, all the while having to deal with upstreams that often don't care about many of these things. I haven't seen any other packaging system that is both nicer and maintains Debian's high standards. Maybe something exists. I think Debian's biggest problem in this area is the documentation. The official docs should be more accessible, but that's a big job that nobody has stepped up to do. Yet.
  - kasabali 2y ago
    I agree completely. On the other hand, it should be recognized there's a difference between packaging for the official repository and packaging done by individual users/sysadmins/developers for distributing independently. Unfortunately all of Debian's tooling and documentation is for the first scenario. I must emphasize, I'm not saying, to quote you, that the documentation should more accessible, but nobody has stepped up to do yet. I'm saying, they're completely fixated in their approach to tailor packaging tools and documentation for creating packages for inclusion in official repository. Debian's tools and documentation for creating ".deb" packages are completely intermingled with their policies for including packages in the official repository. That's where all the complexity comes from. They're mixing the policy (Debian repository rules) and mechanism (deb format), and unless they recognize this, no amount of packaging tools or documentation improvements will solve it. Which is such a shame by the way, because like you said, Debian packaging ecosystem is really powerful and would render a lot of complex machinery devops people use today unnecessary. You can distribute out-of-band updates to data files, push configuration (instead of configuration management) [1], do deployments with virtualenv/gems included (instead of containers) [2], proxy/partial repo mirrors for staged updates/deployments etc. Unfortunately if you decide to it, you'll either have to go with the Debian sanctioned way and tear your hairs because of unnecessary complexity, or you'll go look for 3rd party tools and hunt for blogs posts all over the internet as substitute documentation. [1] https://wiki.debian.org/ConfigPackages https://wiki.debian.org/ConfigPackages [2] I recommend checking out Vincent Bernat's excellent "Pragmatic Debian Packaging" series (https://github.com/vincentbernat/pragmatic-debian-packages https://github.com/vincentbernat/pragmatic-debian-packages) for some examples

by dima55 2y ago

kasabali 2y ago

to be really fair, the tools package maintainers use are more complicated than stuff described in the blog post. Best way to discourage anyone from generating a .deb package is recommending him read the official "new maintainers guide"

dima55 2y ago
To do the stuff the blog post talks about you 'dpkg-buildpackage'. That's it. After years of maintaining packages, I think I decided that much of the complexity is unfortunately warranted. You want stuff to work in all sorts of situations, with all sorts of different other things installed at the same time. You want upgrades to work. You want tests to work and to run, but probably you want to skip them when cross-building. You want the package to be co-installable across architectures. You want the package to be cross-buildable and to be usable to cross-build other packages. And you want your builds to be reproducible. And lots and lots of other things, all the while having to deal with upstreams that often don't care about many of these things. I haven't seen any other packaging system that is both nicer and maintains Debian's high standards. Maybe something exists. I think Debian's biggest problem in this area is the documentation. The official docs should be more accessible, but that's a big job that nobody has stepped up to do. Yet.
- kasabali 2y ago
  I agree completely. On the other hand, it should be recognized there's a difference between packaging for the official repository and packaging done by individual users/sysadmins/developers for distributing independently. Unfortunately all of Debian's tooling and documentation is for the first scenario. I must emphasize, I'm not saying, to quote you, that the documentation should more accessible, but nobody has stepped up to do yet. I'm saying, they're completely fixated in their approach to tailor packaging tools and documentation for creating packages for inclusion in official repository. Debian's tools and documentation for creating ".deb" packages are completely intermingled with their policies for including packages in the official repository. That's where all the complexity comes from. They're mixing the policy (Debian repository rules) and mechanism (deb format), and unless they recognize this, no amount of packaging tools or documentation improvements will solve it. Which is such a shame by the way, because like you said, Debian packaging ecosystem is really powerful and would render a lot of complex machinery devops people use today unnecessary. You can distribute out-of-band updates to data files, push configuration (instead of configuration management) [1], do deployments with virtualenv/gems included (instead of containers) [2], proxy/partial repo mirrors for staged updates/deployments etc. Unfortunately if you decide to it, you'll either have to go with the Debian sanctioned way and tear your hairs because of unnecessary complexity, or you'll go look for 3rd party tools and hunt for blogs posts all over the internet as substitute documentation. [1] https://wiki.debian.org/ConfigPackages https://wiki.debian.org/ConfigPackages [2] I recommend checking out Vincent Bernat's excellent "Pragmatic Debian Packaging" series (https://github.com/vincentbernat/pragmatic-debian-packages https://github.com/vincentbernat/pragmatic-debian-packages) for some examples