Hi Dave et al.,

I pick up the thread here.

As you might have seen, I committed the first version of the new bindist scripts to cvs. I used the branch 'remis-bindist' for the scripts module. The scripts are documented in a new README and the HOWTO reflects the changes. I'd be glad if some of the experts could look over the scripts and comment about them.

Here some remarks about the first round of comments:

On Dec 16, 2003, at 9:00 AM, David R. Morrison wrote:

Hi Remi. My preference would be for you to create a CVS branch in the
scripts module for your changes, and then when you are done and everyone
agrees, we can move them to HEAD.


I have a few corrections to what you wrote:



From the scripts/bindist/HOWTO:

Q: What is needed before I can start making a binary distribution?

A: - You need a working fink installation. However during the build
      phase all but the essential packages will be purged. Thus DON'T
      DO IT on a production system where you relay on certain fink
      packages.
    - The user building the binary distribution must be able to get
      root privilegies on the build machine using 'sudo'
    - The maintainer must have an account at SourceForge.net which
      enables her/him to upload the binary distribution.

This is no longer relevant, actually. The final step in the distribution
process must be handled by the fink-core team, and its something we've
been asked not to document publically. The goal of the HOWTO can be
to describe how to get a working bindist into the (local) bindist
directory.

done.


    - Enough disk space to hold the local binary distribution
      (quantify???)
    - Before making a new binary distribution, the packages used must
      be tagged in cvs with the release number used.

There is a question about "order of events" here. It's true that
everything in the bindist needs to be tagged. On the other hand, it has
often been necessary to make minor repairs to packages as the bindist
is being created. Sometimes, I've tagged everything before I started
and then revised the tags every time I made a "repair." Other times,
I've left the tagging to the end.

I strongly prefer to tag the packages first and move the tag if necessary for those packages which fail. This allows further commits while the bin dist is built. Otherwise you'll have to freeze the tree during the hole build or pay close attention to keep the bin dist consistent.


    - If a binary distribution for the stable tree is built, only the
      stable tree must be enabled (at /sw/etc/fink.conf). Otherwise
      packages might get built against libraries existing only in the
      unstable tree.


There is another consideration here, too: the crypto tree. I always first
build the bindist with the crypto tree disabled, to make sure that we
haven't accidentally put things into the non-crypto tree which depend
on things in the crypto tree. Then I make a second pass, with both
stable/main and stable/crypto enabled.

This is handled automatically in 'bdbuild'. The script defines in which order the categories in the main tree are built. I force the build of each package, i.e. fink is called with 'rebuild' instead of 'build'. This assures that each package going into the bindist has only those dependencies installed which it defines itself. This has the disadvantage, that some packages are built twice. This overhead can be minimised by defining a clever order of the categories. The version implemented in 'bdbuild' is my first best guess.


 There are a few other tweaks which are necessary as well.  Fink is not
 very smart about specifying the default choice, and in the automated
 system, we always take the default choice.  For this reason, I remove
 the various system-foo packages before I start making the bindist.
 (Will be less necessary in 10.3 since most system-foo package are now
  virtual packages and needn't be added or removed.)

This is now handled by 'MatchPackageRegEx' which disfavours any system packages. For this to work you'll need a fink newer than yesterday, Dec 20 2003.


---------------------------------------------------------------------- --
---------


Q: What scripts need to be run to make a binary distribution?

A: # First edit bdenv.csh to set up the site specific settings
    # Then source the file to set up the environment
    source bdenv.csh

# Create the directory structure for a new release, f.e. 7.0. This
# assumes that the packages in cvs used for the binary distribution
# are cvs tagged to 7.0
./bdnewrel 7.0


# Get the sources from cvs and copy them into the dist structure
# excluding those packages which may not be distributed as binaries
./bdsources


    # Next build the deb files for the sources copied in the previous
    # step. Successfully compiled packages are copied into the dist
    # structure, including the source files.
    ./bdbuild

    # After the previous step finished, check the $BDLOG directory for
    # any packages which failed to build (stored in NotBuilt).

    # Create index.php files in the various directories
    ./bdindex

This is obsolete; we no longer have a web server trying to run in the bindist directory, so we no longer need index.php files.

okay


    # Ensure all .deb's etc are uploaded
    ./bdsync

    # Make sure the files are referenced
    ./bdscan

    # Get the Package.gz files online
    ./bdsync


I'm not sure if you changed any of the above scripts, but there are a few problems with the current setup. I guess I'll wait until you are a bit farther along before making them explicit.

I started to build a test bindist for 10.3, up to now it works as expected. Of course only a small part of the packages are built and it will take many days to finish. I guess I will run into a problem with xdvi-system-tetex, which builds against an external tetex. How did you handle this package in former bindists?


Thanks a lot for your comments.

Cheers,
                Remi


--------------------------------------------------------------------- "Sometimes I think the surest sign that intelligent life exists else- where in the universe is that none of it has tried to contact us." Calvin (Bill Watterson)

*********************************************************************
Remigius K. Mommsen                 e-mail: [EMAIL PROTECTED]
University of California, Irvine       URL:    http://cern.ch/mommsen
c/o SLAC                             voice:        ++1 (650) 926-3595
2575 Sand Hill Road #35                fax:        ++1 (650) 926-3882
Menlo Park, CA 94025, US              home:        ++1 (650) 233-9041
*********************************************************************



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to