Hacker News Reader

Comment by antonios | Hacker News Reader

I've always considered the Debian model of support (freeze the world and try to support everything) to be wrong and swimming against the tide. I believe that the only ones capable of supporting a package of a given complexity are the authors themselves, and the distros should just handle packaging (and minimal patching on top if necessary). If the author drops support, then you should either be extremely confident you have an adequately strong team to fork and maintain the package...or just don't.

In my humble opinion, the FreeBSD ports model is better in that regard. That's also why I try to use pkgsrc for various packages when maintaining systems running LTS Linux distros.

View on HN

The reason for the "freeze version and backport security fixes only" is that users need to be absolutely confident that when they ask for security updates, nothing else will mysteriously break.

Yes, and what do you do when the security fix break something else and the distro choose not to backport the fixes to that problem?

That's certainly a risk, but it's less likely to happen than the alternative and all serious distributions have a QA process in place which is designed to catch those issues.

File a bug against the package.

Reason why authors can't support packages is that their views may not represent one of Debian and this is why there external maintainers. E.g we have open source game engine and have launcher to download mods and Debian privacy policies don't allow it to check mod updates by default.

Also there is authors that don't care to support ancient library versions that present in all distributions or simply don't care about anything except static linking. Some people also don't use Linux at all even if their project does support Linux.

As an example, "ancient" for many projects means two years.

That's when enterprises might start considering moving onto that version, so the incentives aren't really aligned here.

> That's when enterprises might start considering moving onto that version, so the incentives aren't really aligned here.

Easier said than done in many environments. RHEL 6, released in 2012, is still supported until 2017!

> Debian privacy policies don't allow it to check mod updates by default.

Just make it opt-in, should be fine to do that.

We have reasons to keep it enabled by default so package maintainer will need to disable it by default anyway. Personally I wish to eventually provide better option to everyone, but that launcher is so unimportant that it's unlikely I'll have time on it in foreseeable future. So I think community of debian provide good option for people that need it.

Also it's of course not a case for our project, but I suppose there is developers who simply don't care about things like privacy or security as much as debian community do and I see no reason why they must spend their time on that instead of actual development.

You could make it a build-time choice and prevent building if the choice isn't made. Then Debian could choose to maintain user privacy and you could choose to violate user privacy.

This is more or less what going to happen in future as we don't have any problems with merging such options. Though real problem still remain: debian need own packages because we simply have different views on how software must behave by default.

This goes completely against the LTS idea but did you know Arch Linux is inspired by the FreeBSD ports model?

> In my humble opinion, the FreeBSD ports model is better in that regard.

How do they handle QA?

Reply on news.ycombinator.com