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

David Kalnischkies kalnischkies+debian at gmail.com
Thu Nov 18 19:04:19 UTC 2010


On Thu, Nov 18, 2010 at 19:30, Andres Mejia <mcitadel at 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 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-dummy
Type: application/octet-stream
Size: 421 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101118/2e730c59/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Packages-dummy
Type: application/octet-stream
Size: 1943 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101118/2e730c59/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: status-dummy
Type: application/octet-stream
Size: 289 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101118/2e730c59/attachment-0002.obj>


More information about the Buildd-tools-devel mailing list