Setting up a Build Environment wiki page badly out of date

[Kaleb]

This wiki page: http://docs.unity-linux.org/development:packaging:setting-up-your-system is very badly out of date. Our whole methodology of building packages has evolved far beyond what it was when this page was first written. We need to give this page immediate attention because it touches on a core part of who we are. The basic way to build a package is now this:

-Install pkgutils & svn (hint: delete /usr/bin/bldpkg from the host box. It can be confused with bldchrt and that can have bad results.)

-Get the latest SVN snapshot

-Download chroots

-Extract chroots

-Set up sudo

-Run bldchrt (hint: for a bit of fun, time your builds: 'sudo time bldchrt -p .')

Do we still need to set up .rpmmacros and .rpmrc? Do we need to edit those files in the chroots?

[Stumpy842]

You are quite right that we have evolved beyond the outdated
instructions on the wiki page you mention. AFA .rpmmacros & .rpmrc, if
you use bldchrt exclusively then you do not need to edit those files
in your chroot environments, because bldchrt will do that for you
automatically. Unfortunately right now (until we get a fix for the
"multiple pkgs satisfy a BR" problem), you WILL need a valid
.rpmmacros & .rpmrc in your chroot environments, in order to use
saddpkg to install the BRs for those pkgs which fail with the Missing
BR: t error...

Further to that, saddpkg depends on the SOURCES & SPECS dirs being
populated with the files from the pkg you are attempting to build in
order to work, so you first need to run bldchrt (without the --clean
option) at least one time on that pkg (in order that it may copy the
sources, patches and specfile to the folders) before running saddpkg,
else saddpkg will error out with missing files errors.

Once all the changes are in place with bldchrt, the builder will need
separate chroot environments for not only the 32bit vs 64bit packages,
but also two additional ones for the PLF packages, one each for 32bit
& 64bit (for a total of four chroot environments). This will be
necessary in order to avoid building non-PLF packages with BRs
provided by PLF packages (a point which was brought up by
Neverstopdreaming and brought to my attention by Matt).

The space requirements for those four will be lessened somewhat by a
novel approach... We plan to have special dirs created in the host
(under /var/lib/bldchrt) to store the cached pkgs which are downloaded
by smart while running bldchrt, and mount those into the respective
chroot environments. The non-PLF environments will have the PLF
channel disabled, while the PLF ones will have it enabled, so we only
need two dirs to accomplish this (one for 32bit and another for 64bit
pkgs). Since the default for bldchrt is to keep downloaded packages in
the cache, this will lessen the amount of downloading needed for any
package which needs both non-PLF & PLF versions built.

Also the goal is to make bldchrt PLF-aware so it will alert the
builder if any pkg has a PLF version as an option in the specfile, and
decide automatically which environment to use based on the presence
(or absence) of a "--with=plf" option as part of the options string
passed with the -b/--bpopts option.

[Custom Processing Unlimited]

Pretty powerful stuff, Stumpy hopefully it will help a non-dev like myself understand how to build packages and become a dev :D as I do so want to... but find myself lacking in actually making that happen.  Worked with Matt for a while, but picked something I thought was simple and tuned out to be not so much.  If i am to have my own branch, I know that packaging has to be part of my skill set in order to be successful (which has been slow-moving on my end) so anything to make this more doable for me (in all envs) will be nice...

was kinda funny, after reading what you said I thought to myself "I actually understand this, and it sounds feasable"... gotta admit, this is an odd feeling for me.  Been into computers all my life and have always been the go-to person for everyone I know... not used to being on the other side of the coin at all... but I digress.  This is good stuff and I can't wait for it's implementation!

--
"Custom" is NOT mass produced... then it's just a product line.
Custom Processing Unlimited

[Paul Grinberg]

The contents of that page are indeed quite out of date. I've been trying to keep http://docs.unity-linux.org/development:packaging:svn much more up to date, especially with references to using bldpkg and setting up the devel environment from a chroot. Do we really need http://docs.unity-linux.org/development:packaging:setting-up-your-system ? Perhaps, a better page to be documented is how to properly create a chroot tar-ball which would contain the correct .rpm* files?

Paul.