6 ms·

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 th

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.

SXX 11y ago
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.
- bbrazil 11y ago
  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.
  - _yy 11y ago
    > 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!
- chei0aiV 11y ago
  > Debian privacy policies don't allow it to check mod updates by default. Just make it opt-in, should be fine to do that.
  - SXX 11y ago
    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.
    - chei0aiV 11y ago
      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.
      - SXX 11y ago
        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.
baldfat 11y ago
This goes completely against the LTS idea but did you know Arch Linux is inspired by the FreeBSD ports model?
_pmf_ 11y ago
> In my humble opinion, the FreeBSD ports model is better in that regard. How do they handle QA?
caf 11y ago
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.
- yxhuvud 11y ago
  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?
  - _yy 11y ago
    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.
  - caf 11y ago
    File a bug against the package.

SXX 11y ago

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.

bbrazil 11y ago
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.
- _yy 11y ago
  > 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!
chei0aiV 11y ago
> Debian privacy policies don't allow it to check mod updates by default. Just make it opt-in, should be fine to do that.
- SXX 11y ago
  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.
  - chei0aiV 11y ago
    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.
    - SXX 11y ago
      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.

baldfat 11y ago

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

_pmf_ 11y ago

> In my humble opinion, the FreeBSD ports model is better in that regard. How do they handle QA?

caf 11y ago

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.

yxhuvud 11y ago
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?
- _yy 11y ago
  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.
- caf 11y ago
  File a bug against the package.