Le 2 juil. 2005 à 22:24, Matthew Sachs a écrit :
On Jul 2, 2005, at 07:26, Peter O'Gorman wrote:
I agree with you. Well, almost :). We need a way to validate package
submissions, and build them automatically. If the validation and
building go
~ okay then they go into this new tree. From the new tree they can be
automatically moved to unstable after, say 3 weeks. The move to
unstable
could be stopped by committer if someone deems it necessary, but
the idea
should be that things make the unstable tree unless someone stops it.
I've been planning on writing the software necessary to support
such a scheme. My plan is to make modifications to buildfink so
that instead of just doing world builds, it can queue up
submissions and rebuild packages on an as-needed basis. It would
then email the submitter back with the build and validation results
and, if everything passes, take appropriate action, such as moving
the package into CVS. It would also make the built .debs available
via apt-get, which would give us a bindist of unstable. I'm pretty
busy with non-Fink stuff through to at least the end of July,
hopefully I'll have it written sometime this year.
We should think about how much manual intervention we want to
require for a package to go into various trees. I like something
similar to what Debian does, where if a package builds, validates,
and doesn't have any critical bugs filed against it, it gets moved
after three weeks. Maybe we have "unstable" for submissions which
build and validate, after three weeks things get moved into
"testing", and then things get moved into "stable" manually.
If there's concern over poorly-written packages even being in
unstable, perhaps fink validate could be beefed up to check for
more things. Are there common problems, or policy violations,
which it doesn't currently check?
Three important things that are not checked at the moment, and I
don't know if it is possible to check them automatically, are:
1 - When a package foo may be actually an alternative for a package
bar, (the case arises for muttng recently in tracker), but needs some
manual action to become an alternative
i.e. it compiles, but overrides some parts of an existing package
2 - When a package has conditional settings; for example
documentation building, if and only if some doc packages are installed.
This is the case of almost all gnome packages.
At the moment, most of them are compiled (or checked, or buildfink)
without gtk-doc installed, and they compile.
But, when gtk-doc is installed, they try to regenerate the doc, and
they do not compile any more.
3 - A package foo at version x compiles, but it is desirable that the
same package foo exists also at version x-1, because otherwise other
packages would not compile
This is, for example, the case for doxygen at the moment, where the
version in unstable is fine, except for kde, which requires a lower
version which is in stable, so that it would not be desirable to put
automatically the version in unstable in the stable tree after yy
days. At least till a version of kde could cope with the version of
doxygen in unstable.
There are probably much more things which fit into those categories
of not easy automation.
Cheers,
Michèle
<http://micmacfr.homeunix.org>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Fink-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-devel
