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

[David Kalnischkies]

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…

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