Re: dpkg.pkgs.cpan.org
Jos I. Boumans wrote:
>
> Currently we're prototyping it -- and we only have one build box, which
> churns out i386 packages on unstable... I'm not sure however that
> grabbing bleading edge software from CPAN and building it on debian
> stable should warrant it being marked 'stable' -- or am i not
> understanding what you mean?
I assume he means "built for stable", as this might include different
dependencies for none Perl code (i.e. C libraries).
By informal conventions it probably ought to be "cpan.backports.org" or
some such.
See http://backports.org/
This is my interest too, where packages aren't already in Debian stable,
it is too late, but it doesn't mean we wouldn't prefer to pick up Perl
code using the normal Debian tools, or distribute software that
explicitly requires adding a perl repository to sources.list.
Where unstable doesn't have a package, someone can of course use your
packages (or the "dh" tools) to build it, and submit it for inclusion in
the core Debian unstable release (assuming they can find a friendly
Debian developer). So in principal, whilst an "unstable" repository is
handy (it might better be called experimental), it shouldn't substitute
for Debian's own unstable repository.
It is likely something 'built for stable' will get traffic from every
ISP trying to get the latest Perl CGI or web application working on
their Debian stable boxes. Where as an 'unstable' repository is likely
to attract mostly developer traffic.
So I think roughly what would be required is;
1. Repository of packages built for unstable, that can be taken into
Debian's unstable repsoitory as needed, or used directly by developers
who just need to get some Perl code to work.
(more or less what you have. Not sure what happens with "source
packages" for perl, as presumable for the migration to the official
Debian repositories it has to work (well have a sporting chance of
working) on all 11 architectures).
2. Repository of "stable" modules, that can be tested.
(can be created by just running your tools on a stable box I expect)
3. Repository of "stable" modules taken from (2) above that are
available at a "back ports" site.
(possibly requires real work, or at least knowledge of the kind of
automated testing Debian does on packages before they are moved to
"testing". Can we also run the Perl "test" suites meaningfully here I
wonder?)
The testing step between 2 and 3, should ultimately be enough to give
confidence that the modules work as well as running cpanplus. I don't
see a huge demand for (2), so it might just be a directory on a disk of
the machine doing the builds for stable, available to some test boxes.
We don't have to recreate Debian's stable procedure, peoples
expectations of third party repositories are somewhat less than their
expectations of Debian's own. But it has to gain at least some
confidence that you can base an operational machine on it, and ideally
also archive the old surpassed packages, so people can backout changes
with confidence, without a reinstall.
At the start 2 can be the same as 3, and the people doing it can learn
as they go what mistakes to avoid - wouldn't be the first time that sort
of process has happened !!!
I'm not a Debian developer, these comments just reflect my understanding
of the release process as an end user - I have a small "x86" biased view
of the Debian world, we run servers under stable, and what to be able to
install Catalyst and similar in one simple, easy command.
The crunch will of course be "how many people" also want to do this, or
how many have found "other" solutions. I know at least some are using
virtual Debian instances to run "testing" or other Debian variants for
clients. Since that will determine the number of volunteers.
Reply to: