- Mine
- Tuesday, August 14th, 2007 at 3:21:52am UTC
- Date: Wed, 17 Aug 2005 15:45:03 -0700
- From: Keith M Wesolowski <[email protected]>
- Subject: Re: Joint Proposal from Steve and Dennis
- To: Eric Boutilier <[email protected]>
- Cc: [email protected], Jim Grisanzio <[email protected]>,
- On Wed, Aug 17, 2005 at 03:31:54PM -0500, Eric Boutilier wrote:
- > I'd like to suggest that we evaluate the JDS team's build process for
- > the Companion CD gate. The following, copied from a post the Glynn
- > Foster (a JDS engineer) posted on opensolaris-discuss, provides a summary:
- >
- > The way we build the Solaris packages using pkgbuild is to
- > basically take the existing Linux spec file, create a Solaris spec
- > file which imports the Linux version, and specifies the various
- > requirements, any additional patches or sources and defines how the
- > package is split up.
- >
- > So take Python for instance. When it migrated from the CCD to JDS, it
- > also migrated from the ON build process to a community-friendly build
- > process; one that is is derived from modern opensource build
- > methodolgies (such as capturing porting knowledge in defacto standard
- > spec-files that are re-usable and machine-readable).
- I agree that we should evaluate it. Here is my evaluation, as it
- applies to the CCD mission of porting arbitrary software to
- {Open,}Solaris and packaging it in a correct and consistent manner.
- It is not intended to apply to GNOME/JDS, which may or may not have
- valid specialised reasons for operating in the manner described. Note
- that in most cases the cost of porting is much greater than the cost
- of incorporating build and packaging information, and that pkgbuild
- offers no help in porting.
- The pros (benefits):
- 1. All Solaris-specific build and packaging knowledge is encapsulated
- into a single specfile instead of one or more makefiles and pkgdefs.
- 2. Red Hat developers have a low barrier to entry.
- 3. Moving packages from the CCD into JDS will be easier, assuming JDS
- retains pkgbuild indefinitely.
- The cons (costs and obstacles):
- 1. Not all software has specfiles. In fact, most doesn't, especially
- if it hasn't been ported to an RPM-based GNU/Linux distribution; if it
- has, it will have different specfiles for each such distribution. Any
- specfiles we do find might be wrong or useless. GNOME is
- well-supported by Red Hat and therefore is likely to have usable
- specfiles, but arbitrary third-party applications and libraries could
- easily have useless specfiles, and the time spent fixing them is time
- that could have been spent porting the software to Solaris or doing
- other work.
- 2. Transition costs. The existing build infrastructure for the CCD
- does not use specfiles, and the knowledge is instead encapsulated in
- makefiles. If pkgbuild were the chosen standard, all package builds
- would have to be converted en masse before any new useful work could
- be done. That's discouraging to new developers and delays meaningful
- contributions. This is not by itself a reason to reject pkgbuild, but
- a cost that must be measured against the benefits.
- 3. pkgbuild is undocumented (and almost entirely uncommented - there
- are fewer than 44 comment lines out of 4447 total). Looking through
- the maze of undocumented, uncommented perl and comparing it with
- Makefile.master, I can estimate it would cost at least 10 times more
- to maintain pkgbuild than freeware-gate's Makefile.master.
- 4. The broader developer community, including our most likely source
- of contributors - Solaris's user base - isn't especially familiar with
- specfiles or RPM.
- 5. Moving packages from the CCD to any other consolidation, or to JDS
- if it abandons pkgbuild, will require all the work that would have
- been needed to implement the package's build in an SFW-like system.
- 6. pkgbuild doesn't use environment variables, so there's no way to
- override paths, tools, or other commonly-customised configuration at
- build time.
- 7. pkgbuild's handling of build-time dependencies assumes that the
- package in question is installed (as a package) on the build machine.
- This is badly broken for intra-consolidation dependencies, which are
- expected to be satisfied by the contents of the proto area and the
- build ordering constraints.
- 8. pkgbuild and even its libraries have a large number of hard-coded
- pathnames and filenames. In some cases it's clear that these are just
- defaults, but others seem to have no way to override.
- Even if some of these costs turn out to be the product of my
- incomplete understanding of the code - which is itself indicative of a
- problem since the SFW and CCD build systems are transparently simple -
- the benefits don't seem to justify any investment in this area, and
- even the less detailed arguments against pkgbuild seem compelling.
- > P.S. We need to let go of the notion that the CCD consolidation process
- > and the SFW consolidation process should be closely coupled. On
- > the surface this coupling seems to make sense (to ON people that
- > is), but I challenge anyone to justify why, in an opensolaris.org
- > world, the SFW process should be derived from the CCD process.
- I can't tell whether you're referring to the development process or
- the build infrastructure.
- --
- Keith M Wesolowski "Sir, we're surrounded!"
- Solaris Kernel Team "Excellent; we can attack in any direction!"
Update the Post
Either update this post and resubmit it with changes, or make a new post.
You may also comment on this post.
Please note that information posted here will expire by default in one month. If you do not want it to expire, please set the expiry time above. If it is set to expire, web search engines will not be allowed to index it prior to it expiring. Items that are not marked to expire will be indexable by search engines. Be careful with your passwords. All illegal activities will be reported and any information will be handed over to the authorities, so be good.