PPAs don't mimic pockets and components support from the Primary archives.

[Philipp Kern]

Use case:

 * Package $foo should be backported to various Ubuntu releases.
 * It uses, say, debhelper 7, which is in hardy-backports but not in hardy proper.
 * Builds of $foo in other releases (i.e. higher than hardy) should not be contamined with backports (thus possibly building against newer libraries and breaking compatibility for users which do not have backports available).

This doesn't seem possible with the current UI.

[Celso Providelo (cprov)]

Hi Philipp,

I see your point, but having archive dependencies configurable at that level seems to make the whole thing way more complicated than it needs to be for the majority of the cases.

We have an alternative, IMHO, enable pockets for some PPAs in need to mimic exactly what happens in the primary archive (only -backports sources have access to -backports binaries).

And for the time being, one can easily represent these different build environments by having multiple PPAs, which seems to have pretty much the same effect for uploaders and users. Do you agree ?

[Philipp Kern (pkern)]

On Sun, Apr 26, 2009 at 10:26:03AM -0000, Celso Providelo wrote:
> I see your point, but having archive dependencies configurable at that
> level seems to make the whole thing way more complicated than it needs
> to be for the majority of the cases.

I'd only activate that if one chooses to get the same components as in
the main archive.

> We have an alternative, IMHO, enable pockets for some PPAs in need to
> mimic exactly what happens in the primary archive (only -backports
> sources have access to -backports binaries).

Somehow I read that this would already be available, but it isn't. Yes,
that would probably be the cleanest approach here. It's maybe not clear
to the endusers that they would need -backports for some distroseries,
though, but one could easily communicate this in the PPA description.

> And for the time being, one can easily represent these different build
> environments by having multiple PPAs, which seems to have pretty much
> the same effect for uploaders and users. Do you agree ?

I really dislike having multiple PPAs just for this. That's like
having one PPA per distroseries so that people don't need to switch
PPAs when, say, backports is required at some point.

But the only pocket which could really screw things up is backports
anyway. I guess I'll go backporting debhelper to the PPA in question
now to avoid this trap.

Kind regards,
Philipp Kern

[Celso Providelo (cprov)]

On Sun, Apr 26, 2009 at 3:23 PM, Philipp Kern
<email address hidden> wrote:
> On Sun, Apr 26, 2009 at 10:26:03AM -0000, Celso Providelo wrote:
>> I see your point, but having archive dependencies configurable at that
>> level seems to make the whole thing way more complicated than it needs
>> to be  for the majority of the cases.
>
> I'd only activate that if one chooses to get the same components as in
> the main archive.
>
>> We have an alternative, IMHO, enable pockets for some PPAs in need to
>> mimic exactly what happens in the primary archive (only -backports
>> sources have access to -backports binaries).
>
> Somehow I read that this would already be available, but it isn't.  Yes,
> that would probably be the cleanest approach here.  It's maybe not clear
> to the endusers that they would need -backports for some distroseries,
> though, but one could easily communicate this in the PPA description.

It's clear if the stuff they have to install is published in the
backports pocket.

The ability to configure PPAs to support pocket & component as in the
PRIMARY archive is not available atm, but it was planned and it won't
be that difficult to get it implemented.

I think it's a elegant and maintainable solution for this problem.

It will become even more necessary when PackageSet becomes a reality
in the Primary archive, PPAs close to ubuntu development will have to
support it as well.

Those things should come in a 'package', "mimic Primary archive"

>> And for the time being, one can easily represent these different build
>> environments by having multiple PPAs, which seems to have pretty much
>> the same effect for uploaders and users. Do you agree ?
>
> I really dislike having multiple PPAs just for this.  That's like
> having one PPA per distroseries so that people don't need to switch
> PPAs when, say, backports is required at some point.

I agree, it's a immediate workaround for those who need the strict
build behavior right now.

> But the only pocket which could really screw things up is backports
> anyway.  I guess I'll go backporting debhelper to the PPA in question
> now to avoid this trap.

-proposed can screw things up very badly, as well. PPAs using it as
build-deps that are not clear about their "experimental" aspect can
ship seriously broken packages.

--
Celso Providelo <email address hidden>
IRC: cprov, Jabber: <email address hidden>, Skype: cprovidelo
1024D/681B6469 C858 2652 1A6E F6A6 037B B3F7 9FF2 583E 681B 6469