#1343 new defect

how does a packager find version requirements for indirect dependencies?

Reported by: davidsarah Owned by: somebody
Priority: major Milestone: undecided
Component: packaging Version: 1.8.1
Keywords: docs Cc:
Launchpad Bug:

Description (last modified by dstufft)

The method of finding Tahoe's indirect requirements documented at http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AdvancedInstall#Dependencies,

  • requires a built copy of Tahoe, and
  • only prints the versions being used by that copy, not the requirements.

The indirect dependencies are pyutil, zbase32, and argparse. It might be easier just to document that (with minimum version requirements if any) and update the documentation manually.

Change History (4)

comment:1 Changed at 2013-10-10T19:53:55Z by dstufft

  • Description modified (diff)

This is actually a pretty hard problem to solve. The issue is that indirect dependencies are not a concrete thing and can depend on what version of direct dependencies get installed (or are already installed).

For instance:

tahoe-lafs depends on foo, foo 1.0 depends on bar, foo 2.0 depends on wat

In the above example there isn't a single set of requirements, it's a tree where the final set depends on what version of foo ends up being selected for installation. It *can* be expressed of course but it can be a very confusing representation if the version specifiers of anything but the root of the tree varies. If they are static then you can collapse the branches into a single branch and you may (in a simple case) get a single set because every combination of dependencies ends up having the same requirement specifiers.

comment:2 Changed at 2013-10-17T15:01:57Z by daira

I'd really prefer to just remove the dependencies on pyutil, zbase32, and argparse (or promote them to direct dependencies if Tahoe really transitively needs them).

comment:3 Changed at 2020-01-16T20:20:16Z by exarkun

Tahoe-LAFS has a lot of transitive dependencies now. If anything, this issue is much worse and more pressing than it was 7 years ago. Yet there is still no particularly good solution.

"Try some versions and see if they work"? That is essentially all the Tahoe-LAFS project does. "some versions" are generally "the latest releases of most things at the time of testing / release".

A package could look at Tahoe-LAFS CI and see what those versions are and pick them. On the other hand, a packager is almost certainly going to use whatever versions of the dependencies someone else has already packaged in the system they are packaging for. And if the result doesn't work ... well, is anyone going to care?

I think it would be great to fix this but I don't know what change is actually going to be helpful, nor to whom. It would probably be better if some *packagers* showed up and asked for something that would help them out. That tends not to happen, though. Packagers are busy and often don't spend a lot of time proactively engaging with upstream.

Maybe no one should use a Tahoe-LAFS packaged by anyone except the Tahoe-LAFS project. That would simplify matters significantly.

comment:4 Changed at 2020-01-16T20:37:10Z by exarkun

This seems awfully closely related to https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1452

Note: See TracTickets for help on using tickets.