PPA page does not include dependencies in the sources.list section

[James Henstridge]

While I can mark one PPA as depending on another one, doing so does not change the suggested sources.list entries from the PPA home page.

As users of the PPA will need to add the dependent PPA too, it would make sense to list the additional entries directly rather than relying on the user to track down the details of the dependency PPA afterwards.

I guess it would be useful to list the PGP keys for the dependency PPAs on the page too.

[Celso Providelo (cprov)]

Do you think PPA dependencies must be always compulsory when you activate one ?

I think It's not always the case and I'm afraid of the confusion it would cause in the UI if we have something like:

{{{
# PPA for James Henstridge
deb http://ppa.launchpad.net/jamesh/ppa/ubuntu karmic main
deb-src http://ppa.launchpad.net/jamesh/ppa/ubuntu karmic main

# PPA for Bazaar Developers (dependency of PPA for James Hestridge)
deb http://ppa.launchpad.net/bzr/ppa/ubuntu karmic main
deb-src http://ppa.launchpad.net/bzr/ppa/ubuntu karmic main
}}}

The fact is that the dependencies might be needed if you want to build sources locally as they would be built in the PPA, however, in most of the cases, they are not needed for installing packages.

Alternatively, we could allow the user to choose if they want the complete dependency chain or only the PPA itself and change the output of the widget accordingly, but I'm a little bit skeptical about the benefits of doing it.

[Julian Edwards (julian-edwards)]

We should probably make it clearer in the UI that the dependencies are really
build dependencies.

[Michael Bienia (geser)]

Even if not needed for every package of a PPA there are cases where the depending PPA is needed for runtime dependencies. Such a case would be if a package is build against a library from the other PPA and also needs this version to run. Not mentioning that a PPA user might need the other PPA to fulfill runtime dependencies doesn't sound right.

[Celso Providelo (cprov)]

PPA dependencies are presented in the PPA page for any user, badly but they are.

The central question here is whether we should always include them in the 'sourceslist' widget or not.

I'm still thinking that build dependencies are not necessary in run time for most of the cases, but one alternative would be to let the PPA owner decide this aspect when he adds a new dependency.

{{{
...
Add PPA *build* dependency: [ ] (Choose…) [ ] also needed in run-time

Extra dependencies: [ ] PPA for James Henstridge (run-time)
                               [ ] PPA for Foo Bar
                               [ ] PPA for Biscuit

<Save> or Cancel
}}}

Unrelated, but it would also be interesting to see which PPAs depends on the PPA you are viewing.

[James Henstridge (jamesh)]

I guess most of the times I've needed one PPA to depend on another it has been for both build and runtime dependencies. Perhaps that is because I've mainly been working with Python stuff where there isn't as big a distinction, but I'd be inclined to believe that most of the build time dependencies are going to be runtime dependencies too.

Are there particular downsides you see to adding the extra sources.list lines?

[Julian Edwards (julian-edwards)]

I think this is probably worth doing then, as long as we can come up with a good UI design. It's also probably worth allowing the PPA owner to decide whether the dependencies need to appear as runtime dependencies for the users as this is not a step to take lightly if the dependent PPA has got loads of packages in it that I might not really want.

[Michael Nelson (michael.nelson)]

It makes sense to include this in the PPA index redesign.

[Michael Nelson (michael.nelson)]

So, we could do the initial work for this as part of the 3-0 redesign (ie. not including the owner setting run-time dependencies etc. or any other change requiring db-changes).

One question I had was whether we'd also need to display the keys for ppa dependencies - Julian had an idea that we could simply include the id/fingerprint in a comment below each the sources.list entry - that would also be useful when removing entries later (ie. to know which keys to remove as well).

[i30817 (i30817)]

No movement on this uh. I guess i should just forget about trying to save work for the launchpad infrastructure and make a duplicate recipe for each project using a certain runtime library that dumps the dependencies on the project ppa archive.

Please reconsider fixing this.