[Lsb-infrastructure] procedure for doing a db-related update

[Mats Wichmann]

I think this will all be familiar stuff, but just for the
sake of being complete:


Steps for applying DB-related update:

1. On an LF machine, apply patch for live database (this will
    require access as the "lsbdbadmin" user or other suitably
    authorized user, check with David Ames for that)

    If it's just a patch, any machine is okay, but you will need:

    export LSBDBHOST=db2.linuxfoundation.org

    In case it's a major update that requires a complete reload, it
    should be done from the db2 machine (otherwise known as 'banner')
    or it will be too slow.

2. in a branch of specdb, "make dump", commit the change, and
    push back to the master branch.  mysqldump on spidey is usually
    used to keep from seeing extra changes to the .sql files.

3. on a regular work machine, pull the specdb branch and "make restore"

4. a. if there are changes in build_env/stub_libs, rebuild there by
    doing "make distclean gensrc".

    b. if there are changes in headers, I tend not to clean-and-build as
    it's very slow (well over an hour for me).  It's not wrong to do so,
    but now that we have the target I tend to just manually do
    "make foo.h-defs" for each affected header foo.h.  However, if using
    this method, if there are NEW headers, it is necessary to also remove
    and regenerate core_filelist in headers (which does desktop_filelist
    as a side effect).  The full clean and rebuild will pick this step
    up automatically.

    c. if there are any added files, either headers or libraries,
    remove and remake core_filelist in the package directory.

    d. update the makefile in package to give this build a new version.
    I tend to bump RPM_PACKAGE_RELEASE for smaller changes and
    SUB_VERSION for larger ones, such as the addition/removal of
    headers or such, no really formal versioning scheme.

    e. commit to bzr and push the build_env branch up to the master:


       bzr push 
bzr+ssh://spidey.linuxfoundation.org/srv/www/bzr/lsb/devel/build_env/

    If there were new files, "bzr add" them first before committing.

5. in misc_test, usually only elfchk, libchk and devchk need
    regeneration, in each case "make distclean gensrc" is fine.
    However, the complication here is that bumping package versions
    for affected packages needs to happen in the separate packaging
    branch. if there are new files, "bzr add" them, then commit and
    push up (both branches)

6. in lsbspec, do "make gensrc" and "make" to generate out the changes
    if they affect the spec.  If new files "bzr add" them, commit,
    and push up.


Some changes ought to be backported to 4.0, but perhaps we'll not
need to worry so much about that.

one can always ask on irc to get consensus on something.