Removing web server dependencies from web apps

[Jérémy Lal]

For info, web apps which are not in PHP like redmine which use Ruby doesn't
depend of apache2 or any other http server.
So why should we depends of it for PHP apps only ?

Because ruby has an embedded web server (webrick), so it doesn't
require one (but it is better for performance and more).

Right, and there have been several discussions concerning webapps :

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627213
http://lists.debian.org/debian-webapps/2010/05/msg00001.html

Also consider continuing this dicussion to
debian-***@lists.debian.org
?

Jérémy.

[Stefano Zacchiroli]

The overall benefit over our virtual package system, possibly in
addition to equivs seems flexible enough. Why do we tailor incomplete
special case solutions instead of recommending equivs more popularly?
I say incomplete, because similar use cases exist for different package
groups - e.g. think of mail servers and database servers. Do we really
want dummy packages for each group of alternatives?
On the other hand, we have a perfect solution which apparently only
needs some more propaganda if even developer don't know it.

You surely have a point here.

At the same time to use equivs one needs to step out of the package
manager interface, which is the most well known interface to install
Debian packages. And is precisely while you're installing packages that
you get (apparently) stuck on the need of a package called
"apache2-mpm-prefork" or "mysql-server-5.1".

I agree we should advertise equivs more as it is the most flexible
solution. But until it is discoverable from (not to mention integrated
with) package managers, I doubt we can make a dent in the number of
people who will get stuck with this.

All in all, having *some* dummy packages in the archive to fulfill
dependencies in non standard setups would cost us very little and save
quite some time for our power users. It will also have the extra
benefit that we keep a tighter control on the existence of such dummy
packages and on their naming, instead of having tons of equivs generated
packages on user machines with random versioning scheme. This aspect
will make easier actions such as removing those packages in future
Debian releases, when we find a better solution.

Copying -webapps, as this discussion should probably continue there.

Cheers.

[Guillem Jover]

Post by Stefano Zacchiroli
I agree we should advertise equivs more as it is the most flexible
solution. But until it is discoverable from (not to mention integrated
with) package managers, I doubt we can make a dent in the number of
people who will get stuck with this.
All in all, having *some* dummy packages in the archive to fulfill
dependencies in non standard setups would cost us very little and save
quite some time for our power users. It will also have the extra
benefit that we keep a tighter control on the existence of such dummy
packages and on their naming, instead of having tons of equivs generated
packages on user machines with random versioning scheme. This aspect
will make easier actions such as removing those packages in future
Debian releases, when we find a better solution.

Steve has already mentioned on the sibling post how those dummy
packages are a bad idea on the archive, but I just wanted to point out
how this would be even worse when integrated with the package manager,
as that would imply easy user accessible bypass of the whole dependency
system. We might as well enable --force-depends all the time.

regards,
guillem