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 to
be present everywhere for their business model to work. A clear
example of
this is Skype.
Now there is a second class of apps/vendors which do not need to be
ubiquitous
for 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
run
Debian.
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
there
anything 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
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/5a6c3020c06664051c1870c929c14...@www.morayallan.com
