Re: Nightly builds of sourceforge (e.g. glx)
In article <[🔎] Pine.LNX.3.96.1000722014349.1389T-100000@eden.nslug.ns.ca>,
Ben Armstrong <synrg@sanctuary.nslug.ns.ca> wrote:
>So, I'm thinking it might be nice to parameterize and package this. If
>someone wants to set up an autobuild, they merely need access to the CVS,
>install & configure the script, and away they go.
The hardest thing in the Drunkard script was a set of rules the worked
on both slink and potato. Then I realized it was nearly impossible to
correctly build packages on slink anyway (how did slink ever get built
with so many bugs in the parts required to build Debian packages, let
alone released?), so I dropped slink support and just upgraded to potato.
Your mileage will probably be easier than my mileage was.
>Or is this inviting disaster because then all kinds of packages of
>questionable quality will proliferate through our user base?
It should be fairly easy to recognize which packages are "official" and
which ones are generated from CVS if users use something like reportbug
to report bugs. If a user _can_ install a binary packaged CVS snapshot
from a site somewhere, then they will, and there's nothing you or I can
do about it except hope that if they're smart enough to edit sources.list
by hand, then they're smart enough to send bug reports to the right
people.
I think the real problem is not users, it's packagers. Building a Debian
package usually requires some sophistication from the packager--they must
understand at least Debian policy and the developer's guide in order to
get the packaging right. Speaking from experience, I know that it takes
a few tries before you get good enough at building sophisticated Debian
packages so that the output packages won't do nasty things to your system,
e.g. by installing packages that refuse to be uninstalled or upgraded
due to maintainer script errors.
There are many opportunities to make simple mistakes that are inevitable
if everyone is going through the procedure manually each time. This is
one of the reasons why debhelper and dh-make exist--to automate the parts
of the task that can be easily automated.
Some of these mistakes are really hard to diagnose with the minimal
information present in most bug reports--e.g. someone might package a
CVS snapshot without incrementing the revision field or changing the
name, resulting in a CVS snapshot package with the same name and revision
as a real Debian package.
If we implement a standard way to turn a CVS snapshot into a
Debian binary package, we also have the opportunity to select a
standard way to identify a package as a CVS snapshot, e.g. by using
"0.0.cvs-snapshot-YYYYMMDD" as a NMU-style maintainer revision number,
and by creating a standard changelog entry. Setting the maintainer
revision is probably the best approach--as a side-effect, if you later
decide to remove the CVS snapshots from your /etc/apt/sources.list,
you will get the "official" package on the next regular maintainer
release through Debian. If Debian releases something before the next
CVS snapshot...well, you get more revisions to test. ;-)
>The whole
>non-free debate has put me on my guard since 6 months ago. Do we really
>want to *encourage* a fragmented pool of debs out there? Is something a
>bit more organized within the project archives needed?
I don't think putting CVS snapshots onto Debian's infrastructure is very
useful (unless someone selects a particular CVS snapshot explicitly as
the upstream source of a package the way they do right now, of course).
After all, an "official Debian package" is supposed to have some
level of human intervention (or minimally _observation_) involved in its
creation--we do hold the maintainer responsible for its bugs, after all.
Packages generated automatically from untested CVS sources are really
useful only for testing purposes--if you want real work done, you
generally want to avoid using binary package of CVS snapshots, but if
you really want to test the packages, then the CVS snapshots are an
extremely convenient way to do so.
The Debian mirror sites probably don't want to host a lot of automatically
generated traffic--the manually generated traffic produces more than
enough load (machine and human) as it is. Imagine if the entire
distribution were rebuilt every two or three days...and uploaded...and
worst of all, downloaded...
I believe Debian should modularize itself around the package dependency
graph, with each module being centered around a package that is a
dependency of many other packages (e.g. packages that depend on perl,
gnome, tcl, python, emacs, etc...), and one module for boot floppies
and CD's (preferably including greater automation for organizing and
generating CD images!). Ideally we would always have some reasonably
current (with a kernel version from the last six months) working
boot/install disks. Each module should have its own short (six months
or so) release cycle, with a progression from unstable through frozen
to stable for that module. These modules would remain part of the Debian
project, with the same distribution sites and the same maintainers,
but with different /etc/apt/sources.list lines, and shorter, (mostly)
independent release cycles. Modules would have to co-ordinate release
dates with their dependents so that stable X works with stable Y, frozen
X works with frozen Y, etc.
To produce a CD, you would just pick the "stable" branch of all the
modules on any given day and put them together. End-users could also
choose where they want to be on the software maturity curve--e.g. stable
base system, stable g++ and libraries, frozen GNOME, and unstable Xfree86.
>Or is it
>sufficient to just make the tools for various CVS sites to put up their
>own snapshots.
While it might be useful to officially collect and maintain the
apt/sources.list lines for these packages, they should not be officially
blessed as "part of Debian", only "a convenient way to participate in the
testing of project X (where X=GNOME, Wine, ...) on your Debian system."
We could have a Debian package whose sole purpose in life is to hold a
list of Debian-like archive sites and allow the user to add (or
remove!) them to (from) /etc/apt/sources.list.
--
Opinions expressed are my own, I don't speak for my employer, and all that.
Encrypted email preferred. Go ahead, you know you want to. ;-)
OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D
Reply to: