On 22/06/07 at 01:49 +0200, Steinar H. Gunderson wrote:
> As discussed during DebConf, I'd like to propose a new release goal: Packages
> should not only build in clean chroots, but also in non-clean environments.
> Specifically, adding extra packages from the archive into the build
> environment (that are not in Build-Conflicts) should not affect the resulting
> package in any noticeable way.
>
> To this end, I've set up the "build daemon from Hell" (BDFH) on my machine,
> currently doing script testing. (Joey Hess has kindly promised to donate CPU
> time on a four-CPU machine so we can push through the entire archive at
> reasonable speeds at regular intervals; the setup will be moved there as soon
> as it's stable.) The idea is to build a package both in a pbuilder and in
> a really filled chroot -- it currently contains 18GB of packages, which is
> most of the "devel" and "libdevel" sections. What is compared is:
>
> - The list of Depends.
> - The list of Recommends.
> - The list of filenames.
I really like the idea.
However, with this setup, you only check that building packages in
non-clean environments doesn't significantly affect the package. It
would be interesting to check as well if the resulting package matches
what is in the archive, to some point. Obviously, packages can't match
perfectly:
- binaries should depend on the same package, but could depend on different
versions (even if Raphael's work will probably mitigate this)
- some files will differ, because of:
+ date/time information
+ newer compiler versions causing better optimization
+ ...
In january, I worked on a script that compares two build results (both sources
and binaries packages), and compared the content of the archive with the result
of one of my rebuilds. The differences were quite huge. Some examples (back
from January of course):
acepack:
r-cran-acepack's depends differ:
-Depends: libc6 , libg2c0 , libgcc1 , r-base-core
+Depends: libc6 , libgcc1 , libgfortran1 , r-base-core
alamin:
alamin-client's postinst differs:
if [ -x "/etc/init.d/alamin-server" ]; then
update-rc.d alamin-server defaults >/dev/null
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
- invoke-rc.d alamin-server start || exit 0
+ invoke-rc.d alamin-server start || exit $?
else
- /etc/init.d/alamin-server start || exit 0
+ /etc/init.d/alamin-server start || exit $?
fi
fi
ada-mode:
files list differ:
-./usr/share/doc/ada-mode/html/Using-non-standard-file-names.html
+./usr/share/doc/ada-mode/html/Using-non_002dstandard-file-names.html
af:
files list differ:
-./usr/lib/menu
-./usr/lib/menu/af
+./usr/share/menu
+./usr/share/menu/af
etc. (you get the idea)
So, I'd like to extend this release goal to something like "binary packages
predictability (to some extend)". This would mostly result in a lot of binNMUs
to update the binary packages to the current state of unstable, so in most
cases, it shouldn't put a lot of load on maintainers.
The number of issues is unknown ; it depends on how close we want packages
to match.
Do you think it's a good idea?
Steinar, do you want to merge your release goal with that one, or do you prefer
me to file a seperate release goal? The main reason why I think they should be
merged is that the way to detect issues is similar.
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
