[buildd-tools-devel] apt-get option to keep dummy packages

[Andres Mejia]

On Thursday 18 November 2010 11:58:24 David Kalnischkies wrote:
> On Thu, Nov 18, 2010 at 15:43, Roger Leigh <rleigh at codelibre.net> wrote:
> > On Thu, Nov 18, 2010 at 09:14:48AM -0500, Andres Mejia wrote:
> >> On Thursday 18 November 2010 05:29:22 David Kalnischkies wrote:
> >> > On Wed, Nov 17, 2010 at 19:55, Andres Mejia <mcitadel at gmail.com> wrote:
> > I'd just like to add that, while we are currently going with the
> > "dummy dependency package" approach to get apt-get to install/remove
> > depends/conflicts, we're open to alternative approaches.
> > 
> > The actual requirement is to
> > - install a list of build-depends
> > - remove a list of build-conflicts
> > - ideally in a single operation.
> > This isn't just a list of packages; it also includes versioned
> > dependencies and alternative dependencies, so what we want to
> > provide to apt-get is basically what you'd have in a Depends:
> > and Conflicts: field and get it to resolve them.  Installing a
> > dummy package is the current approach to getting this information
> > to apt-get, but there may be better ways.  Getting apt-get to
> > install the local package and resolve the deps in a single operation,
> > rather than involving dpkg would be an option, but setting up a local
> > repo is not to easy, considering the need for everything to be signed,
> > but it's something to consider if a feasible approach.
> 
> What i could imagine is an apt-get build-dep ./apt-0.8.9/debian/control
> Shouldn't be incredible hard implement as TagFile-Parsers and co
> are available and the Sources entries are parsed as well on the fly…
> (build-dep itself needs to be seriously improved through)
> 
> > Another requirement not mentioned above that apt and aptitude both
> > currently fail on is the need to resolve alternative and virtual
> > dependencies /predictably/.  That is, we could like it to consider
> > the alternatives in a left-to-right order, picking the first that
> > can be satisfied, rather than treating all alternatives equally.
> > This is to ensure dependencies are resolved in a predictable manner
> > for each build on all architectures.  Virtual dependencies are a bit
> > harder; we currently just pick the first alphabetically--the rule it
> > uses isn't too important, so long as it's totally consistent.
> 
> Its one of the reasons APT (still) exists that people think it is simple
> and predictable - so i am somehow confused why you say the opposite.
> 
> In the event of A | B, APT always tries to install A before it tries B
> (with the only exception that B is already installed in required version).
> And regarding provides: #473247 - the bug exists because APT chooses
> the first provider it can find in the Packages files rather than doing
> something fancy (again, expect one provider is already installed).
> So, again, i would like to ask for an example again…

Here's an example that will exhibit this behavior.
Depends: libvtk5-dev | libopenal-dev
Conflicts: libavcodec52

This is just an example. I'm not aware of any package that has these 
particular package relationships.

libvtk5-dev depends on libvtk5.4 which depends on libavcodec52. libopenal-dev 
doesn't have any relationship with libavcodec52. I expected apt to choose 
libopenal-dev to install. Instead, it removes the dummy package.

> If we are talking about resolvers, its most likely a bad idea to talk
> about APT and aptitude at the same time - as they are completely
> different in their resolver strategies and therefore also in the code…
> They share much (they could share more for my taste), but not that
> for various reasons, included that APT is too dumb aka predictable…
> 
> 
> Best regards
> 
> David Kalnischkies
> 
> _______________________________________________
> Buildd-tools-devel mailing list
> Buildd-tools-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/buildd-tools-devel

-- 
Regards,
Andres Mejia