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

20 years as a Debian maintainer

suihkulokki.blogspot.com

Post reply on HN
Print view View original

71–80 of 126 posts

Re: 20 years as a Debian maintainer

#71

Post by bigger_cheese »

snuxoll wrote: post #37
davexunit wrote: post #22

Earlier quoted context omitted.

I don't think having developers doing the packaging is an ideal situation. I often hear developers complaining about the multitude of GNU/Linux distros because they think it's somehow their responsibility to provide binaries. It's not. The role of the upstream developer is to make their build system easy to use so that other people (like distro maintainers, but also just "regular" users) can compile from source witho…

> tl;dr - Make your software easy to build, don't just package up a mess. You've pretty much hit the nail on the head. You forgot one additional bit though, please for the love of god don't have a crazy web of dependencies. I see a lot of Node and Ruby apps online that I think would be incredibly useful in the Fedora package collection and have considered contributing them on more than once occasion. What always stop…

As a Fedora user the same problem used to exist for Perl packages some packages you could install via yum and some you'd have to get from CPAN. It's been probably a decade since I did anything serious in Perl so not sure if issue still exists but I suspect it still does because I have seen the same issue with python packages and the "PIP" tool.

I see more and more programming languages trying to bundle their own dependency management tools 10 years ago I thought CPAN was great nowadays I'm not as sold it's basically reinventing distro style package management but in a way unique to each programming language.

Re: 20 years as a Debian maintainer

#72

Post by rleigh »

jancsika wrote: post #59
davexunit wrote: post #22

Earlier quoted context omitted.

I don't think having developers doing the packaging is an ideal situation. I often hear developers complaining about the multitude of GNU/Linux distros because they think it's somehow their responsibility to provide binaries. It's not. The role of the upstream developer is to make their build system easy to use so that other people (like distro maintainers, but also just "regular" users) can compile from source witho…

> - Don't bundle third-party dependencies. For security (and for better documentation of the true dependency graph) distros often must go through extra trouble to unbundle third-party libraries when present. Some project even add their own custom patches to their bundled source. Resist the urge to do this. If any of the dependencies aren't currently packaged in Debian, how would one follow this guideline?

Install them separately, but don't embed. CMake provides features like the external project stuff which lets you fetch and build other sources. But even then, you don't need to embed that in your source tree either--do it at a higher level which builds all the dependencies plus your own sources. This keeps your sources free of embedded junk, giving it the flexibility to be packaged, or used standalone.

Re: 20 years as a Debian maintainer

#73

Post by lisivka »

bigger_cheese wrote: post #71
snuxoll wrote: post #37

Earlier quoted context omitted.

> tl;dr - Make your software easy to build, don't just package up a mess. You've pretty much hit the nail on the head. You forgot one additional bit though, please for the love of god don't have a crazy web of dependencies. I see a lot of Node and Ruby apps online that I think would be incredibly useful in the Fedora package collection and have considered contributing them on more than once occasion. What always stop…

As a Fedora user the same problem used to exist for Perl packages some packages you could install via yum and some you'd have to get from CPAN. It's been probably a decade since I did anything serious in Perl so not sure if issue still exists but I suspect it still does because I have seen the same issue with python packages and the "PIP" tool. I see more and more programming languages trying to bundle their own depe…

CPAN packages can be translated into perl packages automatically in many cases, or with little modifications. Same for python, ruby and node packages. See fpm[1] for example of one of such tools.

[1]: https://www.digitalocean.com/community/tutorials/how-to-use-...

Re: 20 years as a Debian maintainer

#74

Post by snuxoll »

bigger_cheese wrote: post #71
snuxoll wrote: post #37

Earlier quoted context omitted.

> tl;dr - Make your software easy to build, don't just package up a mess. You've pretty much hit the nail on the head. You forgot one additional bit though, please for the love of god don't have a crazy web of dependencies. I see a lot of Node and Ruby apps online that I think would be incredibly useful in the Fedora package collection and have considered contributing them on more than once occasion. What always stop…

As a Fedora user the same problem used to exist for Perl packages some packages you could install via yum and some you'd have to get from CPAN. It's been probably a decade since I did anything serious in Perl so not sure if issue still exists but I suspect it still does because I have seen the same issue with python packages and the "PIP" tool. I see more and more programming languages trying to bundle their own depe…

To be fair, all of these language specific package managers make distribution packaging easier as well. It's super easy to make a package for anything distributed as a CPAN package, Ruby Gen, NPM package, distutils/setuptools package, etc.

The real problem comes when developers start using these package managers with reckless abandon and letting their dependency tree grow out of control. I don't mind packaging an extra library or two, but a dozen or more is pushing my patience.

Re: 20 years as a Debian maintainer

#75

Post by dromen »

ausjke wrote: post #68
shmerl wrote: post #63

Earlier quoted context omitted.

What prevents you from using Debian on the desktop? I'm using Debian testing for quite a while already, and it works rather well. The only annoyance is the the freeze period, but it got shorter lately.

Too many software development environments are using ubuntu out-of-the-box these days, I thus follow that to save some setup time. If I use desktop for simply surfing or office needs then yes Debian will be my preference.

Are there specific things you had issues with? Debian Testing still feels more stable and as feature-filled as Ubuntu Xenial to me.

Re: 20 years as a Debian maintainer

#76

Post by digler999 »

Z-Widwil wrote: post #50
SteveNuts wrote: post #41

Earlier quoted context omitted.

I went into systemd with an open mind, hoping the changes would be worthwhile to learn. I've come out the other end looking for alternatives... In the meantime I'll stick to an OS that uses init, and hope systemd get's better given enough time.

Having just set up a Debian server this weekend (Windows dev diving into Linux for the first time), can I ask what the main difference between init and systemd are? Mostly from a operational/security stand point.

without realizing it you casually strolled into one of the biggest points of contention and controversy in computing history.

Systemd came out a few years ago, and wars were fought over it. It fixes a lot of bugs that perennially came up with run scripts, but it's also a huge monolithic program that is in charge of nearly everything on your system.

That's about all I'll say on it, because it's almost as divisive as the Israel/Palestine conflict.

Re: 20 years as a Debian maintainer

#77

Post by dromen »

davexunit wrote: post #51
nrclark wrote: post #44

Earlier quoted context omitted.

Got any advice for ways to bundle stuff written in Rust, Go, Ruby, or Node? All of these languages come with package-managers that encourage reusing packages from their respective ecosystems. I packaged a Github clone called Gogs (written in Go) for Debian/Ubuntu, complete with Lintian support. But I had to compromise on the 'rules' file and add a "get-orig-source" target that uses Go's package manager to grab all of…

There's no easy road. We need to convince upstream to change their ways. The proliferation of language-specific package managers is a problem that many people don't yet understand is a problem. I often get hostile reactions when I advocate for general-purpose systems package managers over language-specific ones. In the meantime, we can use the information available in these language package managers to help bring tha…

I watched the Rust packaging effort via the mailing list, and that seems to be going quite well.

Would you happen to know a good video or writeup on why language-specific package managers are a bad idea? I mean, the situation with C and C++ libraries seems significantly worse to me, and I personally really enjoy having the fully Crates.io index at my disposal on any box that runs Cargo.

Re: 20 years as a Debian maintainer

#78

Post by shmerl »

ausjke wrote: post #68
shmerl wrote: post #63

Earlier quoted context omitted.

What prevents you from using Debian on the desktop? I'm using Debian testing for quite a while already, and it works rather well. The only annoyance is the the freeze period, but it got shorter lately.

Too many software development environments are using ubuntu out-of-the-box these days, I thus follow that to save some setup time. If I use desktop for simply surfing or office needs then yes Debian will be my preference.

I never had such kind of problems when using Debian, but if you need to target a specific distro, you can always add a VM or chroot / container to target it. There is no need to replace the desktop OS to do it. Linux is quite good for such kind of thing.

Re: 20 years as a Debian maintainer

#79

Post by roi »

SteveNuts wrote: post #41
icebraining wrote: post #39

Earlier quoted context omitted.

I'm not rxlim, but considering that the release after Wheezy - Jessie - introduced systemd as the default init systemd, it's not hard to guess.

I went into systemd with an open mind, hoping the changes would be worthwhile to learn. I've come out the other end looking for alternatives... In the meantime I'll stick to an OS that uses init, and hope systemd get's better given enough time.

Let me recommend Void Linux. Its init system is runit, which is djb daemontools based and super simple.

I switched a couple of months ago from Arch, and was surprised at how easy it was, and how completely useless (at least for my use case) all the systemd steaming mess had proved in retrospect to be.

Re: 20 years as a Debian maintainer

#80

Post by snuxoll »

lisivka wrote: post #73
bigger_cheese wrote: post #71

Earlier quoted context omitted.

As a Fedora user the same problem used to exist for Perl packages some packages you could install via yum and some you'd have to get from CPAN. It's been probably a decade since I did anything serious in Perl so not sure if issue still exists but I suspect it still does because I have seen the same issue with python packages and the "PIP" tool. I see more and more programming languages trying to bundle their own depe…

CPAN packages can be translated into perl packages automatically in many cases, or with little modifications. Same for python, ruby and node packages. See fpm[1] for example of one of such tools. [1]: https://www.digitalocean.com/community/tutorials/how-to-use-...

That's great, but distributions rightfully don't allow fpm generated packages. For all of these languages we've already got easy to use infrastructure, but maintaining a dozen or more packages just to get a single app in the repository is a huge commitment.
Post reply on HN