5 ms·

>It's so much harder to build your own software packages on Debian. Even patching an existing Debian package can be painful, and having to write your own packag

by zxzax 5y ago

>It's so much harder to build your own software packages on Debian. Even patching an existing Debian package can be painful, and having to write your own packages is even worse. I can't say that's been my experience, once I figured out dh_make [0] that made it pretty easy by handling most of the boilerplate. Building an existing package is as simple as doing `apt source` and then `dpkg-buildpackage` to rebuild it (you may have to do `apt build-dep` first too). I agree with the rest of your comments though. Edit: I haven't looked into the details of how it works but I would imagine that YMMV with trying to use makepkg that way. The hard part here isn't getting the packages to build, it's in reconciling the library dependencies across all the tens of thousands of packages that make up both distros. [0]: https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to-prepare-debian-packages/ https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to...

bscphil 5y ago
Yeah, I'm vaguely aware of various wrappers that try to make the process easier, I should probably give those a try. Building an existing package is certainly very easy, but I've had problems trying to download the source, apply a patch, and then rebuild it. In Arch this is just "makepkg -o" then "makepkg -e" after you patch the source.
- zxzax 5y ago
  Really? For me it's literally just `dpkg-buildpackage` after patching the source. I never had any problems with it.
  - corndoge 5y ago
    What package and how complex is it?
    - zxzax 5y ago
      I'm not sure I understand the question? This is for any package. Of course you will run into trouble if you introduce breakage, like removing files that the build script expects to be there, or causing merge conflicts with patches applied by the build script. But those breakages can happen with any package manifest, including PKGBUILD.
      - namibj 5y ago
        makepkg -o already applies patches. And makepkg -e after it is like calling it normally, if you don't touch anything in-between.
        zxzax 5y ago
        The difference there is that debhelper will usually try to keep its own modifications temporary, and otherwise keep the source in the same state as the original upstream source. So that way you know when there is going to be a merge conflict.
      - corndoge 5y ago
        When you say making a debian package is easy I want to know what kind of project it is you have experience packaging, like what type of assets has it got, what technologies does it use. How many languages, how many dependencies, how is it linked? That sort of thing
        zxzax 5y ago
        This is just for arbitrary autotools, cmake and meson projects using any language supported by those build systems. The sizes and dependencies vary. I don't really see it being much harder, the debian developer documentation is really convoluted but that's a different problem.
  - usr1106 5y ago
    I would agree that Debian packaging is unnecessarily complicated. The raw stuff is tedious, so various wrappers have been created. In the wild you see a mixture of wrappers and lower level packaging, making everything more complicated for the occasional user. I started with Debian (not as a packager, but just as a technical user who occasionally wants to do his own stuff). Years later I was forced to use rpm and was suprised that things could be so straight-forward. Yet years later I was forced to look at Arch and was suprised again: Hey, you can understand all of it just in a couple of hours. Accumulated experience might result in a slightly biased perception. But I still believe the described gradient exists.
    - zxzax 5y ago
      I can't say I agree with that conclusion, if you're just applying a patch then you don't need to edit the low level packaging. It doesn't affect the occasional user at all.
      - seba_dos1 5y ago
        To be honest, you still do need to grok the difference between native and quilt packages, and, in case of the latter, know that you need to put your patches into `debian/patches/` instead of directly modifying the source tree. And if you started by cloning the packaging from a git repo, you may need to know what pristine-tar is as well. A well-written tutorial will explain that to you quickly, but there's definitely more friction than with PKGBUILD files where you can pretty much just look at the contents of the file and edit it directly without second thoughts.
  - bscphil 5y ago
    The difficulty of figuring out exactly what you need to do is part of the problem. It's hard to shake the feeling that you don't really grok the build system. But in any case it's never been as easy as just running that one command for me. Actual example from my bash history: $ apt source packagename $ vim path/to/broken/file.c $ dpkg-buildpackage Now I get an error: "aborting due to unexpected upstream changes". $ dpkg-source --commit Make a changelog entry for the changes you made $ dpkg-buildpackage This fails with an inscrutable error "dpkg-buildpackage: error: failed to sign .dsc file" If you know what you're doing you realize that you can just ignore this error, it doesn't affect the built package. If you don't, you have to search around and then build it again with $ dpkg-buildpackage -uc So it's not, like, the worst thing in the world but it doesn't go out of its way to be intuitive either. It's hard to find good help on what to do (the man pages are arguably too detailed to be useful to people who just want to make small changes), and hopefully you didn't follow a rabbit trail with debuild.
cookiengineer 5y ago
Disclaimer: Have been an apt shadow for a couple years and ran some PPAs on both launchpad and private servers. Personally, I think the approach that upstream Debian uses in order to not include the headers of libraries with the binary builds is wrong. Nobody has time to deal with over 30 GIGAbytes of hard drive memory that is just there because I wanted to rebuild a damn library of 20kB. That is a total fail, architecture- and build-system wise. As long as Debian separates between distributed binaries, and -dev packages which include all source codes and headers - I would not recommend it for software development. This is the exact reason of PPA fatigue, where end users have sometimes dozens of versions of the same library installed that is also an absolute security nightmare to begin with. Reproducible builds are worth nothing if everybody has to use a PPA of some random untrusted blog post on the internet (omgubuntu anyone?) because Debian's packages are too outdated. Usually those PPAs are heavily outdated as they are built once and then abandoned for years. Libraries are not upgradeable due to how other packages depend on them. They cannot be rebuilt without having to rebuild the whole operating system (have to rebuild X again? Well, gonna stop here then.) Sorry for the rant, but I think in order for DUR to work in practice, these conceptual flaws have to be fixed upstream first.
- zxzax 5y ago
  I'll try to respond to some of your comments, but I'll admit I'm always somewhat confused by rant posts. I never really understood PPAs, that seems like an Ubuntu thing that was not ever suggested to use in debian. If you want to stay on bleeding edge for packages, the suggestion would be to use debian sid. I'm not sure what you mean 30 GB of memory. How is that related? And how would merging the -dev packages into the library packages solve it? IMO there are problems with the Debian approach but I wouldn't say that's one of them -- a worse problem to me is that things like cross-compiling/multi-arch mostly requires chrooting which is a lot less convenient than the approach used by something like Nix.
  - andrewshadura 5y ago
    You don't need to chroot for cross-compiling, Debian supports multi-arch for most of the packages. You just install the cross-compiler, the cross-libc and all native development packages for the architecture you're building for.
creshal 5y ago
> I can't say that's been my experience, once I figured out [dozens of moving parts] That's the whole point. Nobody doubts that the Debian tooling works (it evidently does), but the learning curve to get to that point is massively steeper and longer. Makepkg you can figure out in an hour, at most an afternoon for the finer details like custom patches; reliable Debian packaging takes days or weeks to understand set up.
- _d7dt 5y ago
  I don't think it took me that long. I said this elsewhere but to me that is mostly a documentation problem, not anything to do with the underlying technology or the package format.
- pxc 5y ago
  When I was a teenager, running Arch for about a year in part to take advantage of patched/bleeding edge copies of WINE from the AUR, I decided Arch sucked and to try out Ubuntu (I'd mostly used Gentoo, Sabayon, and openSUSE previously). Recreating the patched packages and setting up my own PPA for them was pretty much trivial. It did not take a whole day to figure out. The Debian system is a little clunky, but it is not hard. If you're a user of Ubuntu or Fedora or openSUSE whatever, learning how to create DEB and RPM source packages and upload them to OBS or Launchpad is way less work than setting up Arch for the first time.

by zxzax 5y ago

bscphil 5y ago

Yeah, I'm vaguely aware of various wrappers that try to make the process easier, I should probably give those a try. Building an existing package is certainly very easy, but I've had problems trying to download the source, apply a patch, and then rebuild it. In Arch this is just "makepkg -o" then "makepkg -e" after you patch the source.

zxzax 5y ago
Really? For me it's literally just `dpkg-buildpackage` after patching the source. I never had any problems with it.
- corndoge 5y ago
  What package and how complex is it?
  - zxzax 5y ago
    I'm not sure I understand the question? This is for any package. Of course you will run into trouble if you introduce breakage, like removing files that the build script expects to be there, or causing merge conflicts with patches applied by the build script. But those breakages can happen with any package manifest, including PKGBUILD.
    - namibj 5y ago
      makepkg -o already applies patches. And makepkg -e after it is like calling it normally, if you don't touch anything in-between.
      - zxzax 5y ago
        The difference there is that debhelper will usually try to keep its own modifications temporary, and otherwise keep the source in the same state as the original upstream source. So that way you know when there is going to be a merge conflict.
    - corndoge 5y ago
      When you say making a debian package is easy I want to know what kind of project it is you have experience packaging, like what type of assets has it got, what technologies does it use. How many languages, how many dependencies, how is it linked? That sort of thing
      - zxzax 5y ago
        This is just for arbitrary autotools, cmake and meson projects using any language supported by those build systems. The sizes and dependencies vary. I don't really see it being much harder, the debian developer documentation is really convoluted but that's a different problem.
- usr1106 5y ago
  I would agree that Debian packaging is unnecessarily complicated. The raw stuff is tedious, so various wrappers have been created. In the wild you see a mixture of wrappers and lower level packaging, making everything more complicated for the occasional user. I started with Debian (not as a packager, but just as a technical user who occasionally wants to do his own stuff). Years later I was forced to use rpm and was suprised that things could be so straight-forward. Yet years later I was forced to look at Arch and was suprised again: Hey, you can understand all of it just in a couple of hours. Accumulated experience might result in a slightly biased perception. But I still believe the described gradient exists.
  - zxzax 5y ago
    I can't say I agree with that conclusion, if you're just applying a patch then you don't need to edit the low level packaging. It doesn't affect the occasional user at all.
    - seba_dos1 5y ago
      To be honest, you still do need to grok the difference between native and quilt packages, and, in case of the latter, know that you need to put your patches into `debian/patches/` instead of directly modifying the source tree. And if you started by cloning the packaging from a git repo, you may need to know what pristine-tar is as well. A well-written tutorial will explain that to you quickly, but there's definitely more friction than with PKGBUILD files where you can pretty much just look at the contents of the file and edit it directly without second thoughts.
- bscphil 5y ago
  The difficulty of figuring out exactly what you need to do is part of the problem. It's hard to shake the feeling that you don't really grok the build system. But in any case it's never been as easy as just running that one command for me. Actual example from my bash history: $ apt source packagename $ vim path/to/broken/file.c $ dpkg-buildpackage Now I get an error: "aborting due to unexpected upstream changes". $ dpkg-source --commit Make a changelog entry for the changes you made $ dpkg-buildpackage This fails with an inscrutable error "dpkg-buildpackage: error: failed to sign .dsc file" If you know what you're doing you realize that you can just ignore this error, it doesn't affect the built package. If you don't, you have to search around and then build it again with $ dpkg-buildpackage -uc So it's not, like, the worst thing in the world but it doesn't go out of its way to be intuitive either. It's hard to find good help on what to do (the man pages are arguably too detailed to be useful to people who just want to make small changes), and hopefully you didn't follow a rabbit trail with debuild.

cookiengineer 5y ago

Disclaimer: Have been an apt shadow for a couple years and ran some PPAs on both launchpad and private servers. Personally, I think the approach that upstream Debian uses in order to not include the headers of libraries with the binary builds is wrong. Nobody has time to deal with over 30 GIGAbytes of hard drive memory that is just there because I wanted to rebuild a damn library of 20kB. That is a total fail, architecture- and build-system wise. As long as Debian separates between distributed binaries, and -dev packages which include all source codes and headers - I would not recommend it for software development. This is the exact reason of PPA fatigue, where end users have sometimes dozens of versions of the same library installed that is also an absolute security nightmare to begin with. Reproducible builds are worth nothing if everybody has to use a PPA of some random untrusted blog post on the internet (omgubuntu anyone?) because Debian's packages are too outdated. Usually those PPAs are heavily outdated as they are built once and then abandoned for years. Libraries are not upgradeable due to how other packages depend on them. They cannot be rebuilt without having to rebuild the whole operating system (have to rebuild X again? Well, gonna stop here then.) Sorry for the rant, but I think in order for DUR to work in practice, these conceptual flaws have to be fixed upstream first.

zxzax 5y ago
I'll try to respond to some of your comments, but I'll admit I'm always somewhat confused by rant posts. I never really understood PPAs, that seems like an Ubuntu thing that was not ever suggested to use in debian. If you want to stay on bleeding edge for packages, the suggestion would be to use debian sid. I'm not sure what you mean 30 GB of memory. How is that related? And how would merging the -dev packages into the library packages solve it? IMO there are problems with the Debian approach but I wouldn't say that's one of them -- a worse problem to me is that things like cross-compiling/multi-arch mostly requires chrooting which is a lot less convenient than the approach used by something like Nix.
- andrewshadura 5y ago
  You don't need to chroot for cross-compiling, Debian supports multi-arch for most of the packages. You just install the cross-compiler, the cross-libc and all native development packages for the architecture you're building for.

creshal 5y ago

> I can't say that's been my experience, once I figured out [dozens of moving parts] That's the whole point. Nobody doubts that the Debian tooling works (it evidently does), but the learning curve to get to that point is massively steeper and longer. Makepkg you can figure out in an hour, at most an afternoon for the finer details like custom patches; reliable Debian packaging takes days or weeks to understand set up.

_d7dt 5y ago
I don't think it took me that long. I said this elsewhere but to me that is mostly a documentation problem, not anything to do with the underlying technology or the package format.
pxc 5y ago
When I was a teenager, running Arch for about a year in part to take advantage of patched/bleeding edge copies of WINE from the AUR, I decided Arch sucked and to try out Ubuntu (I'd mostly used Gentoo, Sabayon, and openSUSE previously). Recreating the patched packages and setting up my own PPA for them was pretty much trivial. It did not take a whole day to figure out. The Debian system is a little clunky, but it is not hard. If you're a user of Ubuntu or Fedora or openSUSE whatever, learning how to create DEB and RPM source packages and upload them to OBS or Launchpad is way less work than setting up Arch for the first time.