On 2013-03-24 12:47, Lisandro Damián Nicanor Pérez Meyer wrote:
There are third party vendors (read: propietary) that support the installation of their software in Debian, but mostly because selfish reasons: they need tobe present everywhere for their business model to work. A clear example ofthis is Skype. Now there is a second class of apps/vendors which do not need to be ubiquitousfor their business model to work. Most of the examples that come to my mind are CAD-related: Synopsys [0], Cadence [1] and Mentor [2] are examples of propietary vendors that give support for Linux but just on Red Hat and sometimes, Suse. And they are a PITA to make them work on Debian. This makes IT workers need to have RH/Suse/CentOS boxes even if the rest of them runDebian.
I'm not sure that the two groups are categorically different. In both cases there's a "critical mass" kind of effect -- people will provide Debian packages if it's an expected thing to do.
Sometimes the Debian support is a *.deb made from the RPM packages with alien, but this is just a small rant :-)
I've seen low-quality third-party packages for Debian and low quality non-packaged installers, from both proprietary vendors and free software projects.
I suspect this only seems more of an issue with proprietary apps because those are the third-party packages that people who otherwise just use official Debian packages end up trying to install.
However, when I have been forced to use some piece of proprietary software on Debian, I have actively preferred using a statically compiled distribution-agnostic version rather than trusting the packages to behave sanely. And I don't want non-free software to start itself except when I ask explicitly, to override existing configuration, etc.
I realise that static builds aren't a good solution for all software (it only really works for "leaf" applications, though all the examples you give fall into this group), or for all users (it requires more knowledge, and aren't a good solution for deployments wider than a single machine), but they may reduce the number of people who ask for Debian packages from proprietary vendors.
Note equally that sometimes there are problems that aren't from the original packaging work, but because packages are left for years without updates to support newer distributions. The situation is parallel with the situation for proprietary drivers for Linux.
Now my question is: without going against the Social Contract, is thereanything Debian can/should do wrt this situation?
Well, we could advertise more heavily to such third parties the heavy use of Debian derivatives as well as Debian itself, and try to persuade them that providing a package that works on Debian allows them to reach all these users. However, this might lead to disappointment when the packages didn't install on a large proportion of the derived-distribution users' machines.
In principle we could solve that by getting more certainty about common base packages with derived distributions, but it seems to me that a lot of effort would be needed to give even a small probability of this happening in a useful way, probably involving significant compromises on Debian's side.
A more practical way to mitigate this problem would be to provide a tool that checks a package for its installability on different Debian versions and on derived distributions and suggests solutions to increase installability, which would only require collecting data rather than reaching social agreements.
-- Moray