Re: Proposal for a new package relationship option
On Sat, Nov 25, 2000 at 01:42:32AM +0200, Gil Bahat wrote:
> On Sat, Nov 25, 2000 at 12:26:49AM +0100, Marcus Brinkmann wrote:
> > On Sat, Nov 25, 2000 at 01:15:08AM +0200, Gil Bahat wrote:
> > > Definition:
> > > Package X discourages Package Y when the two packages can exist in
> > > a stable setup, but may require specific configuration to co-exist,
> > > or their conjunction might cause potentially undesireable effects.
> >
> > I think such two packages must not exist. Either they conflict, or they
> > don't. The default configuration for non-conflicting packages should always
> > allow for a peaceful coexistence, without undesireable effects whatsoever.
>
> well, this way you're forcing users to make a choice they do not
> necessarily want to do. i have a webserver installed, and i want to
> test another one. i want to run two diffrent webservers together
> on a production enviroment for features. or i could have a program
> which supplies webserver as an extra (the realplay servers do that).
> why stop me from doing so then, when it's possible?
I don't want to stop you. The best way to achieve this is to integrate this
flexibility in the Debian packages. Optionally, webserver packages should
configure the port they are running on, for example if the default port is
occupied by an already installed webserver.
This requires a bit more coding, but I am sure you'd agree that this is a much
better solution than acknowledging the deficiancy by introducing a
wishy-washy-conflicts in the packaging system. The proposed new field would
not fix the problem, it would only make it more obvious. The correct fix is
local to the set of affected packages (eg all webservers).
> plus, i suppose you've seen the task-secure thread.
> if not, i'll try to summarize the problem:
> task-secure tries to push secure alternatives to telnet(d),
> but can't conflict on them because it'd *force* people not to have them
> installed.
I think this is stretching the task-* system. The packaging system was
never meant to provide such a fine control. This is much better solved by a
package installation front end which is clued in the functionality of some
packages (for example, which packages are more secure than others with a
similar functionality).
Again, I think that this is much better solved by an alternate strategy,
instead forcing the existing system into something that it was not intended
to handle (and can't handle in an optimal way anyway).
> another issue: security problems. this can add up to debian's security
> by discouraging inherently insecure setups - xscreensaver and nis had
> an issue like this, if i recall correctly. so instead of putting it
> in a comment or doc, the system can now actually reflect this in the
> package relationships.
You are saying this as if adding such a field to dpkg were the only possible
solution, while it is one of the worst.
> > Wishy-washy conflicts will only add confusion to our packaging system.
>
> it might add confusion, that's quite correct. but then again, it adds
> power too.
It doesn't. The power would still have to be in the frontend. Remember
dselects behaviour on recommended packages?
> perhaps it should be configurable? (i.e. configure dpkg
> by default to treat discouragements as conflicts, and allow the power
> users to change that)
> this way,
Yes, it should be configurable, but I think by a specialised tool which
knows what to do.
I agree with you that the situations need a better solution than we have
(multiple webservers, more secure alternatives). But I think those are
better fixed by specialised tools/install scripts/front ends. This will lead
to much more user friendly interfaces, and I think it will also be easier to
implement and keep running in the long run.
However, I am not the dpkg maintainer, so I don't have to decide it. But if
I'd be facing a situation like you describe (read: if I were interested in this
type of problems), I'd try to avoid changing dpkg and seek for a local, more
specialised solution. Just my 2 cents.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: