Check out the upcoming PPAMAIN:
http://lists.debian.org/debian-devel/2013/05/msg00131.html
This would allow us to get our packages into Debian, but not be stuck
with a single version for the whole lifecycle of stable. (Hoping this
relieves some of Greg's concerns.)
-Brian
Full announcement:
"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.
