Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Oct 01, 1999 at 10:20:41AM -0400, Clint Adams wrote:
> > it isn't useful to run the vtund server until it is configured. there
> > is no "standard" configuration which is suitable for shipping as a
> > default - it MUST be customised for each site, each tunnel must be setup
> > individually.
> When did "useful" enter this discussion?
usefulness or utility has always been in this discussion. you should pay
> pipsecd starts the daemon automatically even though no tunnel has
> been set up, and even if userlink-modules hasn't been installed.
> And even though it is of absolutely no use to you, the daemon
> starts running when you install the package. And if there's some
> sort of exploitable back door in the code, you're vulnerable.
> But fine, you think security is a non-issue.
if pipsecd turns out to have a security hole then that MUST be fixed
regardless of whether it is started at install-time or not. fixing
the bug is the solution to the problem. merely not starting it is no
solution at all, that's just hiding your head in the sand.
> You seem to recognize at least one situation where it is
> counterproductive for Debian to make an assumption about the
> user's configuration. Why can you not recognize others?
i have little interest left in this tedious thread, so i'll say this
once and once only. i really hope you can manage to understand it:
vtund was my package to create as i saw fit. I personally saw no need
to have the vtund running when it wasn't yet configured, so I personally
chose not to have it start until the user configured it. The maintainer
of pipsecd, according to your report, made a different choice. that is
this is not a matter for policy, this is not a matter where a tiny
minority of whiners can have artificial hysterics about fantasy security
issues and other FUD. my package, my decision. if you feel that the way
i manage my package is a problem, then file a bug report - i'll evaluate
that bug report and take whatever action (if any) i feel is appropriate.
ditto for the pipsecd package, Samuel can make up his own mind about how
to look after his package.
by the same token, packages containing other daemons belong to their
respective maintainers. if there is any conflict between differing
packages, then it is up to the relevant maintainers to sort out a
solution - e.g. the emacs and xemacs conflict...until the people
responsible for those packages put their heads together and figured it
out, it was not possible to have both installed at the same time. now,
it is no problem at all.
what this means is that if there is a great desire to have several pop
packages installed at once, then it is up to the maintainers of the pop
packages (and other interested parties) to come up with a way that can
be achieved without hassle, and without imposing stupid and onerous
burdens on the maintainers of unrelated packages.