From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a326ac15995ef20e,start X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.scarlet.biz!news.scarlet.biz.POSTED!not-for-mail NNTP-Posting-Date: Mon, 25 Sep 2006 15:17:25 -0500 From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: ANNOUNCE: Debian build scripts on a public Monotone server Date: Mon, 25 Sep 2006 22:18:15 +0200 Message-ID: <871wpzd7js.fsf@ludovic-brenta.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:ZR7G0sBqLifd0eln6lVXT5xUoEM= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 62.235.205.85 X-Trace: sv3-uhwKwmiZXcwS0ouLN54Cnh6kZhOsTVO/o0gspYz2nx7CwDvA7zhmjiEOL3bX1yGFB5ifiMiKVUECx3r!KNHYTz1YCf9b31v8Kxco1SVg/I3isqB/hAv8WfXSF10W/rLMVKvbwZkzcMeqdrNrBEldKD3ujw== X-Complaints-To: abuse@scarlet.be X-DMCA-Complaints-To: abuse@scarlet.biz X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:6733 Date: 2006-09-25T22:18:15+02:00 List-Id: As most of you know, all Debian build scripts are public; you can download them from Debian's many mirrors, change them, and run them to build binary packages. Now, you can also follow their development almost in real-time thanks to Monotone, a powerful distributed version control system. About Debian source packages ---------------------------- A Debian source package consists of three files: * {package}_{version}.orig.tar.gz - the pristine upstream sources. The directory tree in the tarball always starts from {package}-{version}.orig (note: _ in the tarball name but - in the directory name). * {package}_{version}-{revision}.diff.gz - a compressed patch which applies to the above directory tree extracted from the tarball. This patch brings in all of the Debian build scripts, Debian-specific files, and patches. The {revision} is specific to Debian, too, and changes with every upload. The most important file brought by the patch is debian/rules, which is executable and builds the package. Usually (and always for the Ada packages), debian/rules is a Makefile. * {package}_{version}-{revision}.dsc - a short text file containing the MD5 sums of the two above files, and which is signed with the maintainer's private GPG key. In order to build the set of binary packages for a source package, one must therefore: $ tar xzf {package}_{version}.orig.tar.gz $ zcat {package}_{version}-{revision}.diff.gz | patch -p0 $ mv {package}-{version}.orig {package}-{version} $ cd {package}-{version} $ debian/rules binary All these steps, and then some, are automated by apt-get: $ apt-get source --build {package} So, what's the problem? ----------------------- With the above system, you can download and rebuild from source any Debian package from your current distribution (stable, testing, unstable, or experimental). You can change the package itself, or the build scripts. But you cannot: - use older versions of the build scripts - use newer build scripts that have not yet been published to the Debian archives - submit your changes to the maintainer in a clean, efficient and automated way (the official way is by opening a bug report). These problems become critical for the many packages that are maintained by teams rather than individuals. A version control system allows the in-development build scripts to become public, so that team maintenance is possible. For the Ada packages, I would like to encourage people to look at the scripts and propose improvements; maybe even form a team and benefir from each other's experience? Many Debian packages have project pages on Alioth[1], and use one of Subversion[2], GNU Arch[3], Bazaar-NG[4] or GIT[5] as their version control system. [1] http://alioth.debian.org/ [2] http://subversion.tigris.org/ [3] http://www.gnu.org/software/gnu-arch [4] http://bazaar-vcs.org/ [5] http://git.or.cz/ Since I do most of my Debian work on the train and without any network connection, I require a _distributed_ version control system. After evaluating[6] several candidates, I settled on Monotone[7] several months ago. [6] http://www.ada-france.org/debian/distributed_version_control.html [7] http://venge.net/monotone Why Monotone? ------------- I believe that Monotone is the Ada of version control systems, so it is only appropriate that I use it for my Ada work. Monotone is safe, correct and powerful _by design_. It uses cryptographic keys to authenticate changes. It is written by elite programmers who, despite using C++, have the "Ada attitude": no pointers, one assert() every 9 lines of code, massive use of generics (templates), and not a single critical bug in 3 years. The slides at [8] and my own tests convinced me to switch from Meta-CVS several months ago for my Debian packages, as well as for other work. [8] http://www.venge.net/monotone/downloads/codecon-2006.pdf#search=%22monotone%20low-stress%20version%20control%20system%22 A Monotone database consists of one single file; this is very convenient for maintenance. A Monotone database takes only a fraction of the disk space required for an equivalent database in any other system I've tried (Subversion, Bazaar-NG, Mercurial, CVS), which is also an important consideration for me. (I like to think that... CVS is the "C" of version control systems, Subversion is the "C++" designed to replace the "C", GIT is the "assembly language" who needs cogito to be useable, Bazaar-NG is the "perl", grossly inefficient and completely baroque, Mercurial is the "Eiffel" i.e the second best, Monotone is the "Ada", i.e. the best, even if not perfect) (I particularly dislike Subversion and its distributed derivative, SVK. I do not recommend them because their working model is inherently broken, IMHO. A branch is NOT a directory, and a tag is NEITHER a branch NOR a directory. And Subversion does not even try to keep track of merges; just like C++ does not even try to multitask.) What's in the Ada-France database? ---------------------------------- The database that I just published on Ada-France is a replica of the one I work on every day. It contains one branch (sometimes a couple of branches, actually) for each package I work on. Each published upload of each package also has a tag. You can browse the whole history of all changes, with comments. The size of the database is about 1.7 Mb. As of today, "mtn list branches" says: org.debian.adacontrol org.debian.asis org.debian.asis-doc org.debian.asis.2005 org.debian.gnat-gdb org.debian.gnat-glade org.debian.gnat-gps org.debian.libaunit org.debian.libaws org.debian.libflorist org.debian.libgtkada2 org.debian.libopentoken org.debian.libtemplates-parser org.debian.libtexttools org.debian.libxmlada1 org.debian.libxmlada2 The list of tags ("mtn list tags") would be too boring for this post. Each branch contains a "debian" directory and, in most cases, a "patches" directory. I use Quilt[9] to manage the patches. [9] http://savannah.nongnu.org/projects/quilt If you extract an upstream source tarball, and checkout from Monotone into the source tree, you're ready to build the package. The database does not contain the upstream tarballs (.orig.tar.gz); these are available from Debian mirrors anyway or, if not yet published in the Debian archive, from http://www.ada-france.org/debian/pool . How to use Ada-France's Monotone database ----------------------------------------- If you want to *read* from the database: 1. Install Monotone, version 0.26 or later (the server is currently running 0.28). 2. Create a key pair: $ mtn genkey your@email.address 3. Create a new, local database: $ mtn --db=debian.mtn db init (I like to keep all my databases in /var/lib/monotone, but you can place your database anywhere; remember: it's a single file anyway. You can, of course, have as many databases as you want.) 4. Pull all branches starting with "org.debian": $ mtn --db=debian.mtn pull www.ada-france.org 'org.debian.*' 5. Create a working copy: $ tar xzf {package}_{version}.orig.tar.gz $ mv {package}-{version}.orig {package}-{version} $ cd {package}-{version} $ mtn --db=../debian.mtn checkout --branch=org.debian.{package} . 6. Now you can build the package, change the scripts, add new patches and whatnot. More importantly, you can *check in* into your local database, keeping track of your own changes. You can even create sub-branches at will, if you wish your changes to remain separate. (the above commands have abbreviations, e.g. -d for --db=, -b for --branch=, etc.. Also, --db= and --branch= are unnecessary in a working copy, because the working copy remembers the database and branch it was checked out of.) If you want to *write* into Ada-France's database: You can "push" your changes directly to the Ada-France database, too. But I will allow you to do so only if you identify yourself :-) You will need a GPG[10] keypair, signed and part of the Debian Web of Trust[11], in addition to your Monotone keypair. You need not be a Debian Developer; you only need to be authenticated. (The recent debates about copyright law made it plain that anonymous contributions are quite dangerous in fact). [10] http://www.gnupg.org/ [11] http://www.debian.org/events/keysigning.html 1. Extract your public key from your Monotone database: $ mtn --db=debian.mtn pubkey {your@email.address} > your_public_key (your_public_key will be a short plain-text file). 2. Send me your public key in a GPG-signed email (signed with your public GPG key, that is). 3. Wait until I reply to tell you you're good to go. 4. Push your changes: $ mtn --db=debian.mtn push (the database remembers where it was "pulled" from, so by default Monotone will "push" there. You can change that if you wish). Enjoy! -- Ludovic Brenta.