Re: Unmet Deps revisted
On Wed, Jan 13, 1999 at 09:31:07PM +0100, Santiago Vila wrote:
> > > 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.
Considering this is more than 1,000 packages, I don't see why you should
want to install them all.
> If exim is the preferred MTA of choice in Debian, then all the others
> should have extra priority.
It's not the "preferred choice of Debian". There needs to be one that is
used if the user doesn't pick one. It just happens that exim is a good
choice for a system in that case.
> > > 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.
Other than to tell people the source exists.
> > > 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" ].
I'm not so certain that's a good idea actually. Which is the point I am
making (or attempting to at least..)
> > 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.
I don't think Debian should be choosing which software I should use.
> > 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."
Compare to the definition of "extra":
This contains packages that conflict with others with higher
priorities, or are only likely to be useful if you already know
what they are or have specialised requirements.
A package only conflicts with higher priority optional if it's placed
into extra... => Note however I believe the intent is things which
conflict with standard and above packages here as that seems to me to be
a reasonably good use of extra.
Also the hint here is that extra packages are only to be installed if you
know what you're doing.
> 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.
I think you're being very literal about it. By your readon of optional
and my reading of extra, it seems there is a gap between the two.
> > > 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.
I care about global consistancy, I just remain unconvinced this is where
the consistancy is needed. => You've given me things to think about
though and I'm also going to go digging through archives of -devel and
-policy where I expect to find a few things of interest which are
related to this.
--
"Lennier, get us the hell out of here!"
"initiating 'getting us the hell out of here' maneuver."
-- Babylon 5
Reply to: