Re: Bug#331528: ITP: debinstaller -- a graphical frontend for installing local .deb packages

[Daniel Burrows <dburrows@debian.org>]

On Thu, Oct 06, 2005 at 01:50:26PM -0400, Joe Smith <unknown_kev_cat@hotmail.com> was heard to say:
> "Eduard Bloch" <edi@gmx.de> wrote in message 
> >Hehe, it was my first thought about a possible solution, howerver:
> >You also need the Conflicts string. And while the dependencies/conflicts
> >are beeing installed, there may appear a constellation where the new
> >package must be installed during the upgrade. And how would resolve that
> >situation then?
> >
> Very good point, however one slight problem: if the package needs to be 
> installed as a dependency of itself directly or indirectly then there is a 
> circular dependecy which as we know is a bad thing. In fact I'm a little 
> surprised that dependencies are not treated like predepends are, as that 
> would prevent circular dependencies. As they are a bad thing, such a system 
> seems like a good idea.
> 
> I do however ack the potential for problems with 'conflicts', although I'm 
> not sure that that is really a big deal, as installing the dependencies by 
> hand, and then dpkg -i would also have the conflicts situation. 

  The thing is that if you import the package into the apt universe, you
might (very often will) be able to resolve the conflicts cleanly before
you try to install the package, without having to do anything
particularly hacky.  Another thing to consider is what happens if the
user wants to install several .deb files at once, esp. if some of these
depend upon each other and are available in the repository under older
(incompatible/conflicting) versions.

  You might be able to make it work, but it seems much better from a
design point of view to do all this work in the apt layer, so you don't
end up with lots of redundant (and probably subtly different/broken)
code to do what apt already does.

  Daniel