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

Winding down my Debian involvement

michael.stapelberg.ch

Post reply on HN
Print view View original

211–220 of 238 posts

Re: Winding down my Debian involvement

#211

Post by JohnFen »

mongol wrote: post #26
wgjordan wrote: post #5

The post shares several pain points with Debian's slow, aging change-process and integration-infrastructure. Open question: If Debian contributors feel the need to drop out and move on due to these pain points, are there less-painful Linux-distribution projects out there that are getting more of these pain points right they can flock to? Is this a sign that Debian needs to reform, or that other, newer distributions a…

I am surprised OpenSuse does not get more attention. I feel its infrastructure, with the open build service etc, should be aťtractive to many?

The last time I tried OpenSUSE, it gave me nothing but problems. Admittedly, this was many years ago and things may have changed -- but I have no real reason to give it another try to find out.

Re: Winding down my Debian involvement

#212

Post by JohnFen »

z3t4 wrote: post #162

I haven't made any debian packages, I heard it's a lot of work, but these looks good, not bad: * Granting personal freedom to individual maintainers * All maintainers need to read up on what the new thing is, how it might break, whether/how it affects them, manually run some tests, and finally decide to opt in.

I routinely make Debian packages. It's not actually that hard -- unless you're intending to submit them for inclusion in the Debian repository. I don't do that, so I can ignore a lot of the most painful stuff.

Re: Winding down my Debian involvement

#213

Post by JohnFen »

lifeisstillgood wrote: post #19

For me this is the telling part:: """When I joined Debian, I was still studying, i.e. I had luxurious amounts of spare time.""" OSS has stopped (if it ever truly was) being a part time endeavour. I know from bitter personal experience one cannout up with a lot of bureaucracy and process of it is your day job - you have time to get through the rubbish in order to find the diamonds. How we (as a society now utterly dep…

> OSS has stopped (if it ever truly was) being a part time endeavour.

I think that depends on what OSS crowd you want to run with. The part-time hobbyist sector may be, I think, stronger than ever before.

The difference now is that there exists the "commercial" OSS sector. That is certainly not part-time hobbyist.

There is some overlap between those two worlds, but they are very different and distinct worlds nonetheless.

Re: Winding down my Debian involvement

#214

Post by jgoerzen »

Hi Michael,

Thanks for writing this. I wrote a response here: https://changelog.complete.org/archives/9971-a-partial-defen...

The tl;dr version is I agree with you about some of the things you mention, but also feel like there's an element of personal preference for web-based tools showing through.

Re: Winding down my Debian involvement

#215

Post by secure »

rleigh wrote: post #79
xyzzyz wrote: post #21

Earlier quoted context omitted.

Better have fewer high quality bug reports than more low quality reports. The latter just teaches you to ignore them.

It's not just about "low quality" bug reports. The entire system is baroque and messy to use even for experts. I've been using it for 2+ decades now. As a maintainer, I frequently needed to change bug tickets. Tags, versions, dependencies, and other details. All need doing through the control@ email interface. Changes can take over half an hour to be processed and acknowledged. It's inefficient and tedious, and prone…

Thank you for saying this. I’m so glad I’m not alone in my perception :)

Re: Winding down my Debian involvement

#216

Post by sidcom »

msh wrote: post #182
giovannibajo1 wrote: post #18

Earlier quoted context omitted.

Those changes are reviewed by maintainers. The fact that a random stranger is able to push a change and get it reviewed, approved, merged, and available in minutes should be the goal of most open source projects. On the contrary, older projects tend to be too reactionary when it comes to infrastructure tools, so in turn they get very slow interactions. This becomes a demotivator for anybody who is used to more effici…

> The fact that a random stranger is able to push a change and get it reviewed, approved, merged, and available in minutes should be the goal of most open source projects. That sounds like a security risk to me.

I had to re-read it too. He does not say that the same dev should do all these things

Re: Winding down my Debian involvement

#217

Post by kakwa_ »

crehn wrote: post #181
billsix wrote: post #69

Earlier quoted context omitted.

Agreed, I've tried and failed to make Debian packages, and have no idea how to proceed. In contrast, with Gentoo and their documentation, it was straightforward for me to make my own additional, separate repo, look at other ebuilds to see how packaging works, and have everything just work. https://github.com/billsix/billsix-portage I submit ebuilds to Gentoo itself if I think others would benefit. As far as I can tel…

Shameless plug: https://github.com/hoffa/debpack It won't pass all lintian tests due to the ridiculous requirements and useless ceremony "correct" Debian packages need. Still working on it.

Another shameless plug:

https://github.com/kakwa/amkecpak

It doesn't exactly simplify the Debian packaging in my case as it leaves the packaging mostly exposed.

But it provides a lot of far more convenient and easy to remember commands (make rpm, make deb, make deb_repo, make rpm_repo, etc) compared to the easy to forget options of rpmbuild/mock and dpkg-buildpackage/cowbuilder.

It also glues everything together from upstream source recovery to building the final repository ready to be rsynced on a public server.

Re: Winding down my Debian involvement

#219

Post by kakwa_ »

ckastner wrote: post #190
jcoffland wrote: post #66

I've been using Debian for over 10 years and I still love it as a user. But as a developer, I find it extremely frustrating. I've several times attempted to figure out how to package my open-source projects [1] [2] for Debian but the process is a nightmare. As I understand it, I first have to find someone with appropriate privileges to mentor me. I should be able to just submit a potential package for review. Then th…

My first upload will soon be 10 years ago. One thing that is definitely noticeable is that while creating a package is still by no means trivial, it has definitely become much, much easier. 10 years ago, you had a handful of very idiosyncratic build helpers to help you manage your package. Today, effectively it's just one [1], debhelper, and it has become trivial to build packages with it. It's a very powerful framew…

The Debian tooling can be really fantastic at time. If the upstream is clean (project with a proper setup.py/Makefile/CMake/Makefile.pl/etc), you only have to declare the meta-data, the build and runtime dependencies and you are set.

But at the same time, I'm not a big fan of other aspects. For example, the fact the packaging is split between at least 3 or 4 files and generally something close to a dozen (at least control, rule, changelog, copyright and maybe .install, .conffiles, .postinst, .preinst, etc) is a bit complex at first specially compared to rpm where everything is centralized into one .spec file.

I'm also not a big fan of how Debian packages handle permission different than root:root. dpkg-statoverride in post install doesn't feel natural, the newcomer while typically use chown, which is wrong. rpm is better in that regard, you explicitly state the permissions in the spec file %files section.

And I'm also not a big fan of Debian renaming upstream archives (_.orig.tar.gz), IMHO, upstream should be taken as it is, including the file name. But that's a minor one and also a very personal opinion.

I've mixed opinions about packages with a lot of scripting to handle a kind of default but slightly customized configuration. I know it can be disabled with "DEBIAN_FRONTEND=noninteractive" but I feel like it's a lot of efforts and an unecessary source of complexity and bugs for a distribution that will primarily be used on servers where such helpers are almost useless specially using tools like puppet/chef/ansible/saltstack.

The tooling also feels a bit like an aggregation of scripts put on top of each. For example, when you want to build in a clean and throwaway environment (aka a chroot), you have pbuilder, cowbuilder, qemubuilder, whalebuilder... CentOS/Fedora has mock. Granted it's less advanced (apart maybe from mockchain) but at least it the obvious choice.

For a lot of things, the Debian packaging feels like Perl: there is 10 ways to do it. But 9 of them are wrong, and you have to go through dozens of pages of policies with no search box (https://www.debian.org/doc/debian-policy/index.html) to figure out the right way. And it's also kind of difficult to follow examples (by downloading source packages to see how it's done) since it's not explicit where each part fits, at least for a newcomer.

Re: Winding down my Debian involvement

#220

Post by bubblethink »

Conan_Kudo wrote: post #200
bubblethink wrote: post #161

Earlier quoted context omitted.

It's not about RH packages directly. They are fine. As it is with universe on ubuntu, you quite likely need epel on rhel for doing quite a lot of basic stuff. If you are able to get by with just the proper supported packages in each distro, this doesn't affect you. And that's where the two diverge. universe is in better shape since it is semi-official, v/s epel which is completely unofficial/community-based.

Actually, since EPEL is often backports from Fedora, many people elect to keep them up to date with what's shipped in Fedora, so it tends to do better than other counterparts. The closest counterpart is SUSE's PackageHub, which is often seeded by stuff going into openSUSE Leap that isn't part of SLE itself.

Just saw your other comment about Fedora. Thanks for Fedora and EPEL. I was just pointing out that EPEL would benefit from some recognition as a semi-official but ultimately unsupported repo from RH. Technically RH already has 'optional' channels which are already in that category, but EPEL should really be that. Some communication channel between RH and EPEL and QA so that stuff doesn't break on RHEL point releases and maybe some resources for security updates would go a long way in making RHEL more usable.
Post reply on HN