launchpad-users team mailing list archive
Mailing list archive
Re: PPA's and officially supported vs. community-supported (ports) architectures
On Fri, 2009-06-19 at 08:43 +0200, Celso Providelo wrote:
> On Fri, Jun 19, 2009 at 7:41 AM, Martin Pool <mbp@xxxxxxxxxxxxxx> wrote:
> > 2009/6/19 Celso Providelo <celso.providelo@xxxxxxxxxxxxx>:
> > > I understand your problem, although I find it very unlikely that we
> > > will open the gates for binaries generated outside LP, because it
> > > defeats a very important aspect of PPAs, trusted source -> binary
> > > path.
> > It is a bit strange to me that the PPAs would potentially trust
> > Richard to upload source, but not trust him to upload binaries. I
> > suppose source packages have a level of auditability, perhaps after
> > the fact, that binaries do not.
> Exactly, from the user perspective, at least the common one, losing
> the ability to go back to the source, and trace changes, is bad.
> OTOH, I do recognize that this is a policy enforced for the ubuntu
> official repository, not necessarily for PPAs, where the *trust* exist
> between the user and the group of people driving the PPA. At this
> level, if I trust Richard to upload good sources, I will probably
> trust him to upload good binaries for architectures that launchpad
> can't build.
> From the code point of view, accepting binary uploads for unsupported
> architectures wouldn't be that hard to implement, however publishing
> them in a way it's clear that they were not generated by Launchpad
> might be involving (they would not be signed by the default PPA
> signing-key, for instance).
When uploading the binary files to the download area of the bzr project
I was presented with the option to create and simultaneously upload a
signature for each file. By this same mechanism we could provide a
signed binary with a different key than the PPA. No one would
accidentally download these files because they would not be signed by
the PPA key. Instead of unsigned binaries, this would give users the
option to add my public key to their authorization in order to use the
files I provide.
I guess the main thing this provides is a single sources.list line for
all the architectures for a particular package. I suppose an
alternative would be too put a link to the project's download area in
the PPA's description text. What directory hierarchy and
file-name-conventions are required to support apt-get/synaptic/etc? Is
that level of support a possibility for a project download area?
> Anyway, I guess there is a lot of room for discussion in this area so
> the sooner we start them the better.
> I don't think there is any bug already reported that represent this
> request properly. Can you please file one ?
> > > We can always fallback to the official ubuntu backports repository or
> > > the debian one (which was the original way of solving this) and/or
> > Can we get ppc debs into the official backports? If so, that would be
> > a good way to proceed.
> You can get your patches through the official ubuntu backport
> procedure, which will result in an official backport source package
> that will build ppc binaries for the series where ppc is supported.
Isn't ppc last officially supported in Edgy Eft?
P.S. I'm back from vacation ;^)