Re: my 2 cents to PPA evaluation.

["Celso Providelo" <celso.providelo@xxxxxxxxx>]

On 10/15/07, Christian Robottom Reis <kiko@xxxxxxxxxxxx> wrote:
> On Wed, Oct 10, 2007 at 02:56:09PM -0300, Celso Providelo wrote:
> >  1. Enable uploads to post-release pockets in PPA. They would use the
> > respective (and maintained) ubuntu chroots and get build-deps
> > according the target pocket.
>
> I dislike this solution as it will add a layer of complication only to
> work around a technicality (the fact that the chroots hardcode the
> pocket dependencies).

Good point.

> >  2. Wait for 'archive_purpose-specific-chroots' implementation, when
> > we will be able to customize the 'release' chroot for PPA to grab
> > build-deps from post-release pockets.
>
> Either that, or being able to specify the dependencies externally, would
> solve the building side of the problem..

Exactly, this alternative fits better the direction we've just decided to take.

We will reorganize the current chroots to allow total control of target:

 1 archives
 2 components
 3 pockets

Currently we partially do 1 and 2 for PPAs, but the mechanisms used
are not as reliable as they should be.

We will end up with a single chroot per DistroArchSeries model and we
will be able to specify rules for (archive, pocket, component)
entirely in the buildd-master side.

> > Another major side-effect of the second solution is that PPA users
> > (clients) will have to enable all post-release pockets in their
> > systems in other to install possible binary-dependencies required in
> > PPA packages.

sorry, s\other\order :(

> But not the binary-rependency side. Hmm, that is indeed rather an
> unfortunate side-effect; however, in a way it is a separate problem, and
> the problem of being unable to build-depend on newer versions published
> seems to be the worse of the two. What do others think?

Agreed, IMHO, we can work in a solution for this side-effect at the
client side. It doesn't affect (much) the current plans for LP.

[]
-- 
Celso Providelo <celso.providelo@xxxxxxxxx>