[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Developer repositories for Debian



Hello world,

Now with wheezy happy and out the door, we should finally tackle a long
open issue. Developer repositories (AKA PPA) for Debian.

In this proposal we describe how a "PPA" setup properly integrated into
Debian infrastructure *could* look like. Starting from general layout
then going into technical details later on. Obviously this needs much
more than just the FTPTeam to participate, we can think of at least DSA
and the Buildd people, but there might be any number more.

BACKGROUND:
Debian would benefit from having a way for DDs to *easily* be able to
prepare a set of packages, have them autobuilt and distributed to the
users, WITHOUT all the constraints an upload to experimental or unstable
includes.  We intend to provide mechanisms to facilitate this in a way
which will strike a balance between the ease of maintenance by
developers and the ease of use by users while making sure that the
integrity of the existing Debian suites is maintained and the potential
additional legal liability this infrastructure might add is limited.

DEFINITION OF TERMS (and they are lousy, go find better ones!):
 PPA:     Personal Package Archive and used whenever something in this
          document applies to both, PPAMAIN and PPAEXT

 PPAMAIN: a PPA following all rules of the Debian archive and integrated
          into the archive. NEW packages need a full check, policy has
          to be followed, the usual deal.

 PPAEXT:  PPA external to the archive, not integrated. Packages do not
          need to follow the full set of rules of the main archive and no
          NEW processing is done. Maintainer creating a PPAEXT have to
          agree to the Terms of service first, any content is the
          responsibility of the maintainer, not Debian!

Current plan:
We intent to implement PPAMAIN first, and when this is fully working we
into to then setup a different archive to provide the PPAEXT
service. Alternatively a different team can run it, but as much of the
technic behind will be the same, we should ensure to not divide too
much.

Very lousy timeframe:
I plan to put time into this after my vacation, so starting somewhere
early in July. And then it depends how complicated it will be to
implement this into the Debian infrastructure. I know what it takes for
the archive, but I'm entirely out for the buildds and machines and
whatever else otherwise. My hope is to get it implemented and usable
archive side this year.

Obviously help is always welcome, so if you want to help out, keep an
eye on the discussion that I'm sure will arise from this mail - and join
the debian-dak list in July.

USAGE SCENARIOS:
To make it a little bit easier to understand where this is coming from /
leading us to, we thought of a few usage scenarios, together with the
location they should use.

Aggressive Backport:
    This is the "dotdeb.org" scenario.  For whatever reason, people need
    whatever the latest version of php/mysql/apache/nginx/selectyourpoison
    is, compiled for (old)stable, in order to run on their otherwise
    stable servers. User needs this because they want to run the lastest
    version of CmsDuJour which requires brand new versions of php and
    mysql but those packages won't ever get "moved back" into Debian
    proper.

    This can go to PPAMAIN, as it "only" backports a defined set of
    packages already existing in the archive.

Aggressive Experimental:
    This is the daily build of chromium scenario. It might be helpful to
    build a certain set of packages very often in a very recent
    version. Which shouldn't hit unstable yet or shouldn't block
    transitions.
    It probably works best with a limited set of architectures to not
    needlessly overload buildds of smaller/slower architectures.

    This would be another PPAMAIN, as it is merely a variation of the
    backport variant.

Enthusiast Preview:
    This is the "Iceweasel alpha" scenario which might eliminate many
    uses of the current experimental suite or extra archives like
    mozilla.debian.net. Developers can have PPAs for alpha/beta
    releases, which don't get in the way of uploads to unstable that are
    targeting potential fixes to bugs in unstable/testing.

    This is for PPAMAIN. Same set of packages as in the archive, just
    ones with more possible problems.

Preparing Transitions:
     Some base package(s) should be changed in a maybe incompatible
     way. All  of its reverse (Build-)Depends will be rebuild, updated,
     and fixed in  the PPA before they get transferred to unstable.

     PPAMAIN.

Not Policy Compliant:
    A Vendor is distributing  software which is going to be difficult to
    modify to fit Debian policy.  It's therefore not fit for
    distribution along with the traditional Debian components, but the
    PPA creator got the right to distribute this piece further. There
    might not even be source, and it also insists on loading its config
    from /usr/local/sucky.

    PPAEXT, obviously.

Questionably Licensed:
    There is software with a very ambiguous license.  Too much for the
    FTPteam and Debian to accept responsibility for distributing this
    software officially, but the Maintainer is willing to accept the
    responsibility for distributing this software with the understanding
    that, if the legality of distribution is called into question, the
    package will be pulled immediately pending investigation.

    PPAEXT.

Not A Wide Enough Audience:
    There is not enough interest in this package to warrant putting it
    into main.  There are only three of us that actually own the
    hardware which this software targets, so there is no need to build
    it for 13 architectures and put it on all mirrors.

    PPAEXT

Bootstrapping:
    Some packages need to be bootstrapped in contrib because it needs
    time to package all dependencies. But the final packages are
    targeted for main. Supporting such bootstrap processes through PPAs
    would be useful.

    PPAEXT.


ENVISIONED SET OF RULES:
Following is a set of rules special for the PPAs. Please keep in mind
that normal archive/dak rules and behaviour apply to PPA too, unless
specified otherwise in this PPA rule set.

 - any member of the uploading keyrings can create a PPAMAIN using a
   defined interface[1].

 - Names of PPAs will indicate that it is a PPA. Probably will use
   "ppa-$something" or similar.

 - the Debian project is responsible for the PPAMAIN suites and its
   contents. Therefore they follow the same rules for accepting packages
   as any other Debian suite. (NEW, policy, DFSG, you know it)

 - the creator is responsible for the PPAEXT suite and its contents. See
   below for the special rules that apply to PPAEXT.

 - PPAMAIN by default are based on the "main" component of their base
   suite, but the creator can choose to base it on another component.

 - a PPA will have a base suite declared at creation time. This can be
   any suite existing in the main archive. PPAs declared for suites
   which get removed in the main archive (think of oldstable), will be
   removed at the same time.

 - a PPAMAIN can declare version check constraints for packages
   added/uploaded to it. Say, "packages must be newer than stable and
   older than testing" or similar.

 - a PPAMAIN can be created empty or partially filled with packages from
   the base suite. Partially filled will require a list of packages and
   their versions per architecture on creation time. If version checks
   allow it, packages can also be picked from other suites than the base
   suite using a special syntax.

 - a PPAMAIN can have its full package set transferred into its base
   suite  with one command, provided the base suite is configured to
   receive such  transfers. (Currently we imagine only unstable will be
   configured for it, but other suites might gain this feature
   too). Only packages with  versions NEWER than those existing in the
   base suite will be transferred. All version checks of the base suite
   must be fulfilled for the transfer to work.

 - a PPAMAIN shares the pool with the main archive.

 - the list of packages imported from the base suite of a PPAMAIN can be
   changed using the provided interface[1] at any time. This allows
   additions (or updates) from the base suite as well as removals.

 - a PPA can never contain two versions of the same package (exception
   for arch all as in the main archive) at the same time.

 - a PPAMAIN must have packages with unique versions which  have to be
   greater than in the base suite. Package versions are global  for the
   archive, so the ppaname has to be included in the version  uploaded
   to the PPA.

 - a PPA can be free for upload from
   * everyone in the (uploading) keyrings
   * limited to only the creator of the PPA
   * limited to a set of keys (from the uploading keyrings) given at
     creation time / changed by a provided interface later.

 - a PPA by default includes all architectures of the base suite, but
   the creator can select to limit the architecture set at creation
   time.

 - Packages in a PPA are subject to a "Newer Version In Base Suite"
   check, run automagically during maintenance times. If a newer version
   is detected in the base suite, one of various options can happen,
   depending on the setup the PPA creator has chosen:
   * the package is deleted from the PPA
   * the package is updated in the PPA
   * nothing

 - a PPA can be deleted by the creator or the FTPMasters.

 - a PPAMAIN will be autobuild by default, though the exact details of
   how this will be implemented are left to be worked out together with
   the w-b/buildd people during implementation time. This probably
   involves some more changes to allow PPA creators to help with the
   workload around their PPAs.

 - PPA can declare inter-PPA relations. We currently imagine the
   following, but there might turn up more:
    BREAK: The listed PPAs are broken in combination, tools should
           complain and refuse to allow their usage together.
    DEPENDS: The listed PPAs are needed for this one to be able to
             work.

Following are the rules special for PPAEXT service, which will be
implemented later. They apply on top of the rules listed above for
PPAs.

 - any member of the uploading keyrings can opt-in into the PPAEXT
   service. This requires agreeing to the "Terms of Use" of this service
   (to be written).

 - everyone who has agreed to the Terms of Use can create a new PPAEXT
   suite using a defined interface[1].

 - the creator of a PPAEXT suite is responsible for the PPAEXT[2] and
   its contents. Debian does not do any special check like NEW before
   accepting a package upload.

 - in case Debian receives a notice about bad contents in a  PPAEXT,
   this is taken offline (generally at max within 2 days).
   Investigation will follow AFTERWARDS. In case of repeated offense
   from one creator, the key is blocked for any further PPAEXT action.

 - a PPAEXT can be autobuild if the creator chooses so at creation time.
   This will need discussion with w-b/buildd people and DSA and maybe
   legal support from SPI. Maybe we should only support maintainers in
   autobuilding them (say, the w-b infrastructure) but leave the actual
   autobuilding to the creator of the PPAEXT. Maybe we can run the full
   building, maybe nothing at all.

 - the creator of a PPAEXT will be notified via email about any changes
   to a PPAEXT.

 - PPAEXT do not know about components.

 - A log of uploads to the PPAEXT suites is kept.

 - PPAEXT are hosted in a separate dak install, separate public host
   name, separate mirrors. We think this might appear as
   ppa.debian.org. Any webpage associated with them (like, overview of
   PPAEXT repositories or some such) will also appear there.

[1] Most probably it will either be a signed mail or a signed .commands
    style file.
[2] If there are multiple keys allowed to upload to the PPAEXT, it stays
    "THE CREATOR IS RESPONSIBLE". Just to make sure everyone got it: THE
    CREATOR IS RESPONSIBLE FOR THE PPAEXT.

-- 
bye, Joerg, FTPMaster of the day
<liw> we have release cycles, that's why it takes so long to get a
release out; if we had release race cars, things would go a lot faster

Attachment: pgpub1Hr78I3D.pgp
Description: PGP signature


Reply to: