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

21–30 of 103 posts

Re: DUR: The Debian User Repository

#21

Post by brainless »

AussieWog93 wrote: post #10

Linux does not need more package managers. It creates nothing but support burdens and busywork for developers (yes, user repositories too). I don't understand what people expect to achieve by further fragmenting a minority OS that makes up only 3% of Desktop users.

- Market share is not the most important metric, resilience matters and Linux distributions have only gained in acceptance over years

- People have a fear or even aversion toward experiments since it needs effort, but some folks are simply geeks - they will keep trying and more power to them

- Some of these experiments, historically, have brought some of the best open innovations in the industry and moved even closed-source rooted companies to change mindset

- Fragmentation is a marketing problem IMHO and I would like to see some ground between that and a consolidated Linux distro but it will not happen easily and that is OK

- The enthusiasts like us do not need every other mainstream user on Linux but I am sure we would love that (I am a Linux user for 18 years)

- This community is happy learning and trying new things, it is joyful

So, more power to experimentors. The value of this community is in choice in a market that is dominated by the Apples and Microsofts who do not care about choice.

Re: DUR: The Debian User Repository

#23

Post by kijin »

throwawaaarrgh wrote: post #16
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 suffi…

It's okay to ride a bicycle instead of a car, or vice versa. It's not okay to put bicycle tires on a car, or a car transmission on a bicycle.

I have no complaints about distros that are either 100% systemd or 100% init scripts. The problem with Debian (and its derivatives) is that they're trying to maintain both at the same time.

If they really want to support both "/etc/init.d/servicename start" and "systemctl start servicename" commands, one should be turned into an empty shell that simply invokes the other, like what Red Hat did with the "service" command. The current system kinda works out of the box, but goes out of sync as soon as you try to customize either the init script or the unit file.

Re: DUR: The Debian User Repository

#24

Post by usr1106 »

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.

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.

Re: DUR: The Debian User Repository

#25

Post by andrewshadura »

zxzax wrote: post #17
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…

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

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.

Re: DUR: The Debian User Repository

#26

Post by viraptor »

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…

> 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 upgradeable due to how other packages depend on them.

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

Re: DUR: The Debian User Repository

#27

Post by usr1106 »

Can anybody explain me what is the purpose of the element-desktop-bin package? It just takes the binary from the packages.riot.im repo. That's what I do, too, by having packages.riot.im in my sources.list.d. Why repackage it?

Re: DUR: The Debian User Repository

#28

Post by andrewshadura »

kijin wrote: post #23
throwawaaarrgh wrote: post #16

Earlier quoted context omitted.

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

It's okay to ride a bicycle instead of a car, or vice versa. It's not okay to put bicycle tires on a car, or a car transmission on a bicycle. I have no complaints about distros that are either 100% systemd or 100% init scripts. The problem with Debian (and its derivatives) is that they're trying to maintain both at the same time. If they really want to support both "/etc/init.d/servicename start" and "systemctl start…

In fact, init scripts are only used by systemd when there are no corresponding native unit files.

Re: DUR: The Debian User Repository

#29

Post by zxzax »

andrewshadura wrote: post #25
zxzax wrote: post #17

Earlier quoted context omitted.

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

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.

Last time I tried that I had bad problems with package conflicts trying to overwrite files, but it was a while ago and maybe I was doing something wrong, I'll give it another shot.

Re: DUR: The Debian User Repository

#30

Post by tapia »

I think this is great. I am an arch user at home, but at work I use Ubuntu. It is really difficult sometimes to get the latest version of a software installed in an easy way. I tend to use a lot of custom Makefiles for this, but I don't really like to not use the package manager. Being an arch user, I always wished it was as easy to build deb packages as it is to build packages with makepkg. I tried the debian way, and could successfully build some packages, but it is not at easy at using PKGBUILD files and I have to eventually. Now it seems to be possible to do this in Ubuntu! I will definitely try this!
Post reply on HN