FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-01-2011, 05:17 PM
Andreas Barth
 
Default PPA

* Roger Leigh (rleigh@codelibre.net) [110501 19:04]:
> WRT the signing key, there would need to be some form of trust path
> or else the signature would be worthless. If packages are being
> uploaded to Debian infrastructure, and are under our control, can't
> we use a single signing key? We presumably verified the integrity
> and origin of the package on initital upload, so we should be able to
> use a generic signing key surely? If this is provided in a package
> then we can trigger automated installation of it.

I'd prefer the form that we currently do for e.g. backports: We import
the key on chroot creation, see APT_KEYS in 99builddsourceslist.
Advantage: we don't need to touch chroots if keys changes.


> The main thing sbuild needs would be the information to add to
> sources.list, signing key packages etc. This would probably require
> passing from buildd, so probably more a question of how buildd will
> be configured and get the information to pass to sbuild.

buildds already receive a yaml-file from wanna-build, so part of the
question is easy answered.

For testing purposes, one could make an easy wanna-build with
something like:

#! /bin/bash

if echo $* | grep needs-build -q; then
echo "devel/package_version [optionalut-of-date]"
exit 0;
fi

cat <<EOF
- package:
- status: ok
- pkg-ver: package_version
- key1: value1 (etc)
EOF

(should be enough for handing out packages to buildd, replacing all
package by the package name, and version by the package version)


Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501171736.GM15003@mails.so.argh.org">http://lists.debian.org/20110501171736.GM15003@mails.so.argh.org
 
Old 05-02-2011, 04:28 PM
Jan Hauke Rahm
 
Default PPA

On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> * Raphael Hertzog (hertzog@debian.org) [110501 18:23]:
> > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > build-dependencies not satisfiable in the target suite)
>
> Why not just use one location - shouldn't be an issue unless you plan
> to have the same packages and version numbers in multiple PPAs. And
> that's something I recommend not to do.

I guess I'm misunderstanding you here, so please help me out. If a
package is being worked on in different PPAs regarding different
problems (thinking of serializing transitions for instanced but many
other examples apply), how can they share the same version number
without conflicting?

Hauke

--
.'`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org
 
Old 05-02-2011, 05:16 PM
Andreas Barth
 
Default PPA

* Jan Hauke Rahm (jhr@debian.org) [110502 18:34]:
> On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> > * Raphael Hertzog (hertzog@debian.org) [110501 18:23]:
> > > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > > build-dependencies not satisfiable in the target suite)
> >
> > Why not just use one location - shouldn't be an issue unless you plan
> > to have the same packages and version numbers in multiple PPAs. And
> > that's something I recommend not to do.
>
> I guess I'm misunderstanding you here, so please help me out. If a
> package is being worked on in different PPAs regarding different
> problems (thinking of serializing transitions for instanced but many
> other examples apply), how can they share the same version number
> without conflicting?

Well, the combination of version number and package name needs to be
globally unique. Otherwise, consider what would happen if someone
reports a bug against a package/version, and we can't see which one it
was.

That doesn't mean two packages have the same version number - in
contrast, they don't. But as you usually can't coinstall different
versions of e.g. the same library, that's all fair.



Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110502171647.GV2657@mails.so.argh.org">http://lists.debian.org/20110502171647.GV2657@mails.so.argh.org
 
Old 05-02-2011, 05:21 PM
Jan Hauke Rahm
 
Default PPA

On Mon, May 02, 2011 at 07:16:47PM +0200, Andreas Barth wrote:
> * Jan Hauke Rahm (jhr@debian.org) [110502 18:34]:
> > On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> > > * Raphael Hertzog (hertzog@debian.org) [110501 18:23]:
> > > > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > > > build-dependencies not satisfiable in the target suite)
> > >
> > > Why not just use one location - shouldn't be an issue unless you plan
> > > to have the same packages and version numbers in multiple PPAs. And
> > > that's something I recommend not to do.
> >
> > I guess I'm misunderstanding you here, so please help me out. If a
> > package is being worked on in different PPAs regarding different
> > problems (thinking of serializing transitions for instanced but many
> > other examples apply), how can they share the same version number
> > without conflicting?
>
> Well, the combination of version number and package name needs to be
> globally unique. Otherwise, consider what would happen if someone
> reports a bug against a package/version, and we can't see which one it
> was.
>
> That doesn't mean two packages have the same version number - in
> contrast, they don't. But as you usually can't coinstall different
> versions of e.g. the same library, that's all fair.

In other words, you're suggesting some kind of versioning scheme for
PPAs in order to avoid version conflicts?

Hauke

--
.'`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org
 
Old 05-02-2011, 05:30 PM
Andreas Barth
 
Default PPA

* Jan Hauke Rahm (jhr@debian.org) [110502 19:22]:
> On Mon, May 02, 2011 at 07:16:47PM +0200, Andreas Barth wrote:
> > > I guess I'm misunderstanding you here, so please help me out. If a
> > > package is being worked on in different PPAs regarding different
> > > problems (thinking of serializing transitions for instanced but many
> > > other examples apply), how can they share the same version number
> > > without conflicting?
> >
> > Well, the combination of version number and package name needs to be
> > globally unique. Otherwise, consider what would happen if someone
> > reports a bug against a package/version, and we can't see which one it
> > was.
> >
> > That doesn't mean two packages have the same version number - in
> > contrast, they don't. But as you usually can't coinstall different
> > versions of e.g. the same library, that's all fair.
>
> In other words, you're suggesting some kind of versioning scheme for
> PPAs in order to avoid version conflicts?

No.

We started with "where can we take the package for building", and I
said "there should never be two different packages with same name and
version, so they all can be in one sources list".

There are different possibilities to resolve this - I'm not saying
that I have a perfect solution. But we need to make sure the
combination of package name and version is globally unique. As we do
today.


Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110502173035.GW2657@mails.so.argh.org">http://lists.debian.org/20110502173035.GW2657@mails.so.argh.org
 

Thread Tools




All times are GMT. The time now is 12:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org