Live data from Hacker News

DUR: The Debian User Repository

dur.hunterwittenborn.com

61–70 of 103 posts

Re: DUR: The Debian User Repository

#61

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…

> 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. Is that the case for some specific languages? -dev packages for C and other compiled libraries do not include the full source code of the library. Normally they only include the headers, pkgconfig, and similar files. > Libraries are not upgradeab…

> Got some examples where it's a problem and not an actual dependency issue?

Try to recompile mesa or say, just the demos (aka glxgears) :) Worst case scenario for Debian dependencies.

Re: DUR: The Debian User Repository

#62

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?

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

Header files are literally less than a couple kB per package, and Megabyte-sized headers are the exception for huge frameworks like QT or GACL. Arch packages don't ship the source codes, only the binaries (.so files) and headers (.h files).

Overall, the /usr/include folder on my system has less than 230MB, which is a damn lot because I have all kinds of compilers, programming languages and libraries installed. I even have 32Bit and atmel libraries installed because I do embedded reverse engineering and cross-compiling development on other architectures; so I also have gcc, LLVM, rust, go, C/C++ and other programming languages and their dependencies installed. So it's very likely much less than that for others.

If you cannot afford that, you should maybe choose another, smaller, distribution like "Damn Small Linux", Alpine or similar. Debian wouldn't be a good choice for that matter anyways.

Re: DUR: The Debian User Repository

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

This is off-topic, but the reason why I stay away from Arch is that it has not once, but twice, just fucked itself from right under me. First time around I was just getting up and running and as I installed python3 there was some mismatch between some very core libraries and I couldn't roll back since the library in question wasn't available anywhere, but python3 package (or something that came along with it) was lin…

I've had similar experiences long ago but not in the past .. seven years or so, and i use it as a daily driver. In fact I've encountered less bugs on arch, which follows upstream, than on other distros which often have their own patches and unsupported backports with their own problems.

I have had once a serious bug which rendered my computer unbootable, which i couldn't have solved without my fifteen something years career helping me. But it wasn't an arch issue, i would have had the same thing on debian.

Re: DUR: The Debian User Repository

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

This is off-topic, but the reason why I stay away from Arch is that it has not once, but twice, just fucked itself from right under me. First time around I was just getting up and running and as I installed python3 there was some mismatch between some very core libraries and I couldn't roll back since the library in question wasn't available anywhere, but python3 package (or something that came along with it) was lin…

> Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice.

I disagree 100%. This laptop I'm typing from now was installed 2014-07-06, it's my main personal machine with all the random things your typical desktop does and it works great. I similarly used a work laptop almost as long until I was forced off Arch for compliance reasons this year (sigh). Your anecdotal failures are not everyone's experience, definitely not mine.

Re: DUR: The Debian User Repository

#65

Earlier quoted context omitted.

> 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. Is that the case for some specific languages? -dev packages for C and other compiled libraries do not include the full source code of the library. Normally they only include the headers, pkgconfig, and similar files. > Libraries are not upgradeab…

> Got some examples where it's a problem and not an actual dependency issue? Try to recompile mesa or say, just the demos (aka glxgears) :) Worst case scenario for Debian dependencies.

I meant an example of what the issue is. Glxgears seems to have reasonable dependencies (https://packages.debian.org/buster/mesa-utils) gl1 and glu1 are not even restricted on versions.

Re: DUR: The Debian User Repository

#66

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…

I’ve only just started running Arch. One thing I don’t understand is the AUR security model. Aren’t you running arbitrary code / binaries built by some stranger on the interwebs on your machine? This is my biggest hesitation, and why I haven’t used AUR.

Using the 80/20 rule, most AUR packages are simply the build script ("PKGBUILD") instructions and perhaps a patch if required, etc. (or say adding a missing .desktop file). The process involves your AUR tool (I use "pikaur") downloading them, then executing the build instructions _locally_ on your device. So your desktop is actually the one downloading the real source code and compiling it, then installing it.

The 20% side of this is yes, there are some prebuilt binaries in AUR - usually because (a) they are vendor proprietary code with no source (Zoom, for example) or (b) so insane to build that the vendor does it and you use their binaries (Firefox for example - it's a monster to compile). Most of the time these packages are clearly labeled, usually with "-bin" in the name so you can easily avoid them.

You are executing build instructions written by someone else, but the tools encourage you to actually review them (and pikaur for example can show them to you for review right then and there). There is a level of trust involved and yeah, bad actors do try and slip in ugly things but they're usually found pretty quickly because folks are actually reviewing-before-installing as encouraged. It's risk management on this one, you take some personal responsibility for using AUR to pay attention.

Re: DUR: The Debian User Repository

#67

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…

I’ve only just started running Arch. One thing I don’t understand is the AUR security model. Aren’t you running arbitrary code / binaries built by some stranger on the interwebs on your machine? This is my biggest hesitation, and why I haven’t used AUR.

The idea is you read the PKGBUILD/install files so it's no longer arbitrary code, they're usually very short files. On updates you can review just a diff. AUR helpers present this to you so it's not a manual process

Many packages are compiled from source rather than using prebuilt binaries, but when binaries are fetched it is something you'd see in the PKGBUILD itself. The binaries aren't included in the AUR itself, they'd usually be from the first-party of the software you're installing. For example google-chrome[1]'s package fetches the .deb from Google's server and unpacks it

[1]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=googl...

Re: DUR: The Debian User Repository

#68
post #64

Earlier quoted context omitted.

This is off-topic, but the reason why I stay away from Arch is that it has not once, but twice, just fucked itself from right under me. First time around I was just getting up and running and as I installed python3 there was some mismatch between some very core libraries and I couldn't roll back since the library in question wasn't available anywhere, but python3 package (or something that came along with it) was lin…

> Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice. I disagree 100%. This laptop I'm typing from now was installed 2014-07-06, it's my main personal machine with all the random things your typical desktop does and it works great. I similarly used a work laptop almost as long until I was forced off Arch…

> This laptop I'm typing from now was installed 2014-07-06,

It goes beyond anecdotal evidence. I mean, if you look at the Arch news feed[0], there are a good few updates since then that are labelled "requires manual intervention". I like Arch and it's great they're posting those notices, but I don't think it can be claimed that upgrading an on-the-edge system is always problem free.

[0] https://archlinux.org/news/

Re: DUR: The Debian User Repository

#69
post #64

Earlier quoted context omitted.

This is off-topic, but the reason why I stay away from Arch is that it has not once, but twice, just fucked itself from right under me. First time around I was just getting up and running and as I installed python3 there was some mismatch between some very core libraries and I couldn't roll back since the library in question wasn't available anywhere, but python3 package (or something that came along with it) was lin…

> Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice. I disagree 100%. This laptop I'm typing from now was installed 2014-07-06, it's my main personal machine with all the random things your typical desktop does and it works great. I similarly used a work laptop almost as long until I was forced off Arch…

I have the similar experience to the OP. The last time I had 700 packages or so updating, pressed Ctrl+C (apt or brew never left my system in a broken state after Ctrl+C) and the system no longer worked after reboot. Had to update all packages via a bootable Arch image on a USB to fix it. Also had KDE and Gnome behave weirdly after update to the point of having to reboot immediately – never happened on Ubuntu LTS. Arch is amazing as long as everything is fine but if you do something wrong, it’s far more fragile. I guess it’s ok for a pro user distro but my servers will remain on Debian. Also, I had Arch on an old laptop I use from time to time and it happened at least a few times that if I did not turn it on for 3 months or so, the system was no longer upgradable.

Re: DUR: The Debian User Repository

#70

Earlier quoted context omitted.

This is off-topic, but the reason why I stay away from Arch is that it has not once, but twice, just fucked itself from right under me. First time around I was just getting up and running and as I installed python3 there was some mismatch between some very core libraries and I couldn't roll back since the library in question wasn't available anywhere, but python3 package (or something that came along with it) was lin…

I've had similar experiences long ago but not in the past .. seven years or so, and i use it as a daily driver. In fact I've encountered less bugs on arch, which follows upstream, than on other distros which often have their own patches and unsupported backports with their own problems. I have had once a serious bug which rendered my computer unbootable, which i couldn't have solved without my fifteen something years…

Both of these incidents were during last 3 years. Last one was less than 6 months ago.

I am currently back on ubuntu 20.04 and haven't had any issues

Post reply on HN