Re: Unmet Deps revisted
On Wed, 13 Jan 1999, Joseph Carter wrote:
> On Wed, Jan 13, 1999 at 02:55:50PM +0100, Santiago Vila wrote:
> > What happens is a complete disaster. Examples:
> >
> > smail is still optional, but conflicts with exim, so it should be extra.
>
> Why? I can understand why sendmail for example is in extra, it's a
> scarey program and unless you know what you're doing you should probably
> not use it. But how do other MTAs fit a similar description?
Because if smail is optional then you can't install all the optional
packages as well as all the essential, required, important and standards
packages.
If exim is the preferred MTA of choice in Debian, then all the others
should have extra priority.
> > hello-debhelper conflicts with hello, and has absolutely no extra
> > functionality over ordinary hello, so the binary should be removed, in
> > either case it should be extra.
>
> Again, WHY? hello and hello-debhelper are only there to show you how a
> package is built. It provides the extra functionability of being built
> with debhelper.
This extra "functionality" is only in the source, not in the .deb, so I
don't see why the .deb has to exist at all.
> > gmc conflicts with mc, but both are optional.
>
> Once again, why is this a problem? When there was mutt and mutt-i both
> were optional. They conflicted and replaced eachother. Are you saying
> this was wrong behavior in general?
In general, yes, but please note that I'm talking about main, not about
non-us, contrib or non-free.
I maintain myself conflicting packages, unzip and unzip-crypt, but they
are on different trees, one is in non-free and the other in non-us.
[ But maybe unzip-crypt should be the only one being optional and unzip
should be "extra" ].
> Conflicts and dependancies are what
> make Debian better than dists like slackware. You cannot seriously
> expect to be able to make every single optional package install because
> there are just too many programs that exist and do the same exact thing.
> What you're asking us to do is to decide for the users which programs are
> the best when there is a case where two programs serve the same purpose
> but cannot serve that purpose at the same time.
We *already* do this for MTAs, I don't see the difference between MTAs and
any other set of programs which "serve the same purpose but cannot serve
that purpose at the same time", as you have described.
> This is IMO unreasonable. There may be a good reason for it to be as you
> suggest, but just doing it so the user can "install everything" is not a
> good reason. If I'm missing something here please feel free to correct
> me on this; I simply do not see an issue here.
Just read the definition of "optional" in the packaging manual:
"This is all the software that you might reasonably want to install if you
didn't know what it was or don't have specialised requirements."
Since I don't think it is reasonable at all that the user will want to
install packages that conflict at each other, from the above definition it
is automatically derived that there should not be conflicts between
optional packages.
> > There are in total *ten* dselect Dependency/conflict resolution screens.
> > (using the PageForward key). Am I *really* required to report them *all*,
> > or may I ask our kind ftp.debian.org maintainers to do a *serious*
> > dependency/conflict check *before* the deep freeze?
>
> You had to go through a lot of work to bring up this situation in the
> first place. I think you more or less got what you asked for in this
> case.
I don't think so. I guess that when Debian was small and young, it
was almost consistent. However, it has grown so much lately but we have
just not cared lately about its global consistency.
--
"b15c1e4136502f5f0b7b0fc062f1fefb" (a truly random sig)
Reply to: