Live data from Hacker News

Why does Debian change software?

blog.liw.fi

31–40 of 210 posts

Re: Why does Debian change software?

#31
post #16

The point about manual pages has always seemed to me to be one of the points where the system fails us. There are a fair number of manual pages that the world at large would benefit from having in the original softwares, that are instead stuck buried in a patches subdirectory in a Debian git repository, and have been for years. This is not to say that Debian is the sole example of this. The FreeBSD/NetBSD packages/po…

Usually the Debian manual page author or package maintainer will send that upstream. Same goes for patches. Sometimes upstream doesn't want manual pages, or wants it in a different format, and the Debian person doesn't have time to rewrite it.

Re: Why does Debian change software?

#32

Do distro maintainers share patches, man pages, call home metrics and other data with other distros’ maintainers (and them back)? Further, do they publish any change information publicly?

They usually send everything upstream, and everything is public in their source control. Some maintainers look at repology.org to find package stuff from other distros.

Re: Why does Debian change software?

#33
post #4

Debian will remove code that “calls home” or tries to update software in a way that bypasses the Debian packaging system. Thank god. I'm so happy that such a distro exists.

I'm glad that opensnitch is available in Debian trixie too, to mitigate the issues that Debian has not found yet.

Re: Why does Debian change software?

#34

Do distro maintainers share patches, man pages, call home metrics and other data with other distros’ maintainers (and them back)? Further, do they publish any change information publicly?

> ... do they publish any change information publicly?

This is utter FUD, of course they do, it is an open source distribution. Everything can be found from packages.debian.org

Re: Why does Debian change software?

#35

All of these reasons are good, but they're not comprehensive. Unless someone can tell me what category Debian's alterations to xscreensaver fall under, maybe. As far as I can tell, that was just done for aesthetic reasons and packagers disagreeing with upstream.

The patches and their explanations are listed here:

https://udd.debian.org/patches.cgi?src=xscreensaver&version=...

Edit: can't find any that are for aesthetic reasons.

Re: Why does Debian change software?

#36

Not the best name for the article. My first guess was version changes, or software being added/removed from repo. Turns out this is about source code modification.

As a native (British) English speaker, I was also unclear until reading the article. Personally, I believe s/change/modify would make more sense, but that's just my opinion. That aside, I'm a big fan of Debian, it has always "felt" quieter as a distro to me compared to others, which is something I care greatly about; and it's great to see that removing of calling home is a core principle. All the more reason to have…

Patching out privacy issues isn't in Debian Policy, its just part of the culture of Debian, but there are still unfixed/unfound issues too, it is best to run opensnitch to mitigate some of those problems.

https://wiki.debian.org/PrivacyIssues

Re: Why does Debian change software?

#37

This is one of the reasons I switched to RHEL 10+ years ago. I actually prefer the RHEL policy of leaving packages the way upstream packaged them, it means upstream docs are more accurate, I don't have to learn how my OS moves things around. One example that sticks out in memory is postgres, RHEL made no attempt to link its binaries into PATH, I can do that myself with ansible. Another annoying example that sticks ou…

I don't think that's true for Red Hat, but it is true for Slackware.

If you want packages that works just like the upstream documentation, run Slackware.

Debian does add some really nice features in many of their packages, like a easy way to configure multiple uWSGI application using a file per application in a .d directory. It's a feature of uWSGI, but Debian has just package it up really nicely.

Re: Why does Debian change software?

#38
post #31
post #16

The point about manual pages has always seemed to me to be one of the points where the system fails us. There are a fair number of manual pages that the world at large would benefit from having in the original softwares, that are instead stuck buried in a patches subdirectory in a Debian git repository, and have been for years. This is not to say that Debian is the sole example of this. The FreeBSD/NetBSD packages/po…

Usually the Debian manual page author or package maintainer will send that upstream. Same goes for patches. Sometimes upstream doesn't want manual pages, or wants it in a different format, and the Debian person doesn't have time to rewrite it.

This.

And often it's not an unhelpful upstream, just an upstream that sees little use for man pages in their releases, and doesn't want to spend time maintaining documentation in parallel to what their README.md or --help provides (with which the man page must be kept in sync).

Re: Why does Debian change software?

#39

Do distro maintainers share patches, man pages, call home metrics and other data with other distros’ maintainers (and them back)? Further, do they publish any change information publicly?

There should be a source package for every binary package, and patches are usually in a subdirectory of the package.

Re: Why does Debian change software?

#40

This is one of the reasons I switched to RHEL 10+ years ago. I actually prefer the RHEL policy of leaving packages the way upstream packaged them, it means upstream docs are more accurate, I don't have to learn how my OS moves things around. One example that sticks out in memory is postgres, RHEL made no attempt to link its binaries into PATH, I can do that myself with ansible. Another annoying example that sticks ou…

Pretty much everyone has had nano as default for ages, at least that's how it seems to me from having had to figure out which package has script support and installing vim myself after OS install for a long time.

And RedHat does a lot of fiddling in their distributions, you probably want something like Arch, which is more hands-off in that regard. Personally, I prefer Debian, it's the granite rock of Linux distributions.

Post reply on HN