Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DUR: The Debian User Repository

dur.hunterwittenborn.com

Post reply on HN
Print view View original

31–40 of 103 posts

Re: DUR: The Debian User Repository

#31

Post by corndoge »

zxzax wrote: post #12
corndoge wrote: post #11

Earlier quoted context omitted.

What package and how complex is it?

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.

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

Re: DUR: The Debian User Repository

#33

Post by tinus_hn »

cookiengineer wrote: post #13
zxzax wrote: post #3

Earlier quoted context omitted.

>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 (yo…

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

So you would rather have them waste that exact same amount of space on every computer, just so you don’t have to download it when you want to build a package?

Re: DUR: The Debian User Repository

#34

Post by creshal »

zxzax wrote: post #3
bscphil wrote: post #2

I'm excited to see someone is working on this. I have considered switching from Arch to Sid in the past, mainly so that I could run the same OS on all computers and because I like the DFSG. Two things have stopped me: * 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'm sure a dedicated en…

>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 (yo…

> 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.

Re: DUR: The Debian User Repository

#35

Post by creshal »

tinus_hn wrote: post #33
cookiengineer wrote: post #13

Earlier quoted context omitted.

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

So you would rather have them waste that exact same amount of space on every computer, just so you don’t have to download it when you want to build a package?

I don't have any Debian machine that doesn't end up with build-essential and dozens of header packages installed; it just comes up too often. Adding the header files directly to the packages saves time and frustration, and probably even saves space since a lot these packages are 50% overhead (dpkg meta files, db entries, etc.) by size.

Re: DUR: The Debian User Repository

#36

Post by forgotpwd16 »

akvadrako wrote: post #32
symlinkk wrote: post #22

Snap and Flatpak made distro specific user repositories like this obsolete

Only for apps. They aren't really suited for libraries or even command line tools.

Not suited but possible. Snap allows packaging both libraries (e.g. GNOME runtime libraries) and command line tools (e.g. htop). Although those will live under /snap rather on common Unix paths (/usr/lib and /usr/bin), it just means those will work across distros rather on a specific one.

Re: DUR: The Debian User Repository

#37

Post by zxzax »

corndoge wrote: post #31
zxzax wrote: post #12

Earlier quoted context omitted.

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.

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

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.

Re: DUR: The Debian User Repository

#38

Post by zxzax »

usr1106 wrote: post #24
zxzax wrote: post #7

Earlier quoted context omitted.

Really? For me it's literally just `dpkg-buildpackage` after patching the source. I never had any problems with it.

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…

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.

Re: DUR: The Debian User Repository

#39

Post by _d7dt »

creshal wrote: post #35
tinus_hn wrote: post #33

Earlier quoted context omitted.

So you would rather have them waste that exact same amount of space on every computer, just so you don’t have to download it when you want to build a package?

I don't have any Debian machine that doesn't end up with build-essential and dozens of header packages installed; it just comes up too often. Adding the header files directly to the packages saves time and frustration, and probably even saves space since a lot these packages are 50% overhead (dpkg meta files, db entries, etc.) by size.

I don't install build-essential on a server, in a container, on a VM, etc. It really matters in those places. If you combine them then you lose the ability to deploy a small rootfs.

Re: DUR: The Debian User Repository

#40

Post by _d7dt »

creshal wrote: post #34
zxzax wrote: post #3

Earlier quoted context omitted.

>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 (yo…

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

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.
Post reply on HN