Re: apt-get should correctly process dependencies
On Wed, Apr 26, 2000 at 10:51:11PM +0100, Pedro Guerreiro wrote:
> > > > > After all, what's the use of having a default MTA, if the packages
> > > > > don't pick it up when thay need a MTA? ;-)
> > > >
> > > > Because of the default installs? :)
> > >
> > > Uh? Shouldn't the default installs pick up Important packages and not any
> > > others?
> >
> > Yes, the default installs, but not other kinds of installs.
>
> And you point is?
When the user already has an MTA, a mail-transport-agent dependency
shouldn't change it to get the default one, that's what I meant.
> > > > Depends: real-package-providing-virtual-package-foo | virtual-package-foo
> > >
> > > Are maintainers _really_ helping, are are they just confusing apt?
> >
> > Yes, they are helping. Presuming the latter package exists. In this case it
> > does not, and this is a bug.
>
> This is a bug from mailx (AFAIK already submitted), but can't apt be enhanced
> to work around this?
It worked around it, by going on to the other part of the pipe. (it failed
doing that, but that's another issue)
> > > From what I've said earlier, shouldn't it be
> > >
> > > Depends: virtual-package-foo
> > >
> > > and leave it up to apt to pick up the default package that provides
> > > vitual-package-foo? This way when we changed a default (like when we changed
> > > from smail to exim for the default MTA) things wouldn't break.
> >
> > Perhaps, but what I said is implemented now and works fine. And with other
> > packaging tools such as dselect.
>
> Yeah, right. "It's working. Nobody dare to touch it." Great way to make
> improvements. :-(
The improvement in excluding it is that we wouldn't have to change those few
packages that use default-foo | virtual-foo when changing the default foo.
The negative effect would be that we could no longer have Depends:
preferred-foo | virtual-foo, and that we'd have to implement logic to deal
with the virtual package in dselect and others.
It seems to me that the negative sides outweigh the positives, feel free to
disagree...
> > > > However in this case the first component doesn't exist, so something went
> > > > wrong with apt-get logic...
> > >
> > > Yeah, well what went wrong? :-) Maybe the help of the maintainers? ;-)
> >
> > No, apt-get should have ignored the missing dependency because of the OR
> > condition ("|"), and picked zmailer-ssl or whatever, not bail out.
>
> Well, then _there_is_ a bug in apt. What the hell am I complaining about
> since the beggining?
Well, I didn't say that there was no bug in APT :)
--
Digital Electronic Being Intended for Assassination and Nullification
Reply to: