5 ms·

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 sourc

by 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.

by SXX 11y ago

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.