On Thu, Nov 18, 2010 at 19:30, Andres Mejia <mcitadel@gmail.com> wrote: > On Thursday 18 November 2010 11:58:24 David Kalnischkies wrote: >> On Thu, Nov 18, 2010 at 15:43, Roger Leigh <rleigh@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@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. Again a reason to ditch the --fix-broken mode in favor of an archive or at least for something more cleaner - if such a package is installed from an archive apt happily works out what you want/expect… (see attached apt testcase, drop into test/integration/ ) I will have a look later why APT doesn't work it out in --fix-broken… Best regards David Kalnischkies
Attachment:
test-dummy
Description: Binary data
Attachment:
Packages-dummy
Description: Binary data
Attachment:
status-dummy
Description: Binary data