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

11–20 of 103 posts

Re: DUR: The Debian User Repository

#11

Post by corndoge »

zxzax wrote: post #7
bscphil wrote: post #6

Earlier quoted context omitted.

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.

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

What package and how complex is it?

Re: DUR: The Debian User Repository

#12

Post by zxzax »

corndoge wrote: post #11
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.

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.

Re: DUR: The Debian User Repository

#13

Post by cookiengineer »

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…

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.

Re: DUR: The Debian User Repository

#14

Post by thayne »

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…

> The systemd integration is currently quite bad. It's probably the source of a bunch of user complaints about systemd.

I haven't used plain Debian, but this has been my experience with Ubuntu. Almost all the problems I've run into with systemd have been because of an interaction with init.d scripts that should be systemd units, or similar. My biggest complaint is that while systemd-resolved is supposed to be optional, on Ubuntu it is practically impossible to fully disable without breaking things, and disabling is officially "unsupported". On archlinux, if you want to use dnsmasq instead it is just a matter of disabling one service and enabling the other.

Re: DUR: The Debian User Repository

#15

Post by doubleunplussed »

da_big_ghey wrote: post #9
brainless wrote: post #4

Nice effort, the Arch User Repository is one of the benefits of the Arch way I feel. I have become so used to simply search "arch aur " or whatever I am looking for, finding it there, git clone and install. I keep installing random userspace software and I do not think AUR let me down. On a side note, I keep thinking there are so many great ideas spread over the many Linux distributions and not having a single joint…

If you are think search and git clone are nice, waiting until you find out of AUR helper! `paru -Syu visual-studio-code-bin`

It's almost certainly a conscious choice to not use an AUR helper

Re: DUR: The Debian User Repository

#16

Post by throwawaaarrgh »

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…

> On the whole, Debian administration is a lot more complicated than on Arch because of the relative complexity of the architecture.

This should be expected though. Debian has been around a lot longer and is depended on by more of the Linux world. Complexity is a natural outcome of more stakeholder requirements (more stakeholders = more requirements = more complexity).

I won't get into the systemd holy war, but suffice to say that comparing the architecture of init scripts vs systemd is like comparing the design of a bicycle to a car. One most definitely is more complex than the other, but whether that's a good thing or not depends on what you want to do with it.

Re: DUR: The Debian User Repository

#17

Post by zxzax »

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…

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.

Re: DUR: The Debian User Repository

#18

Post by namibj »

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.

makepkg -o already applies patches. And makepkg -e after it is like calling it normally, if you don't touch anything in-between.

Re: DUR: The Debian User Repository

#19

Post by brainless »

doubleunplussed wrote: post #15
da_big_ghey wrote: post #9

Earlier quoted context omitted.

If you are think search and git clone are nice, waiting until you find out of AUR helper! `paru -Syu visual-studio-code-bin`

It's almost certainly a conscious choice to not use an AUR helper

I agree it is a conscious choice, I read it from the Arch Wiki, but to be honest I do not know why this can not be solved and accepted as a way forward.

Re: DUR: The Debian User Repository

#20

Post by zxzax »

namibj wrote: post #18
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.

makepkg -o already applies patches. And makepkg -e after it is like calling it normally, if you don't touch anything in-between.

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