OpenCSW

The different issues can be tracked on the Roadmap.

"Bratislava" release notes:

• Why CSWcommon at all? Better provide dirs and symlinks in each package
• Make separate tree in GAR, like, bratislava/pkg/cpan-TermReadKey/
• GAR together with release in bratislava/gar/
• Parametrizable:
  • Package Prefix FOO instead of CSW
  • The build recipes can therefore specify packages names without stem, like this which would result in either FOOmypkg or CSWmypkg depending on the setting of PKG_STEM: PACKAGES += mypkg
  • Directory Prefix /opt/csw, /etc/opt/csw, /var/opt/csw
  • default user and group foo:bar instead of root:bin
  • We may need a new CSWcommon which adds user foo and group bar
  • The new FOO-world is always built with the CSW-packages in /opt/csw
  • The names of the class action scripts must also be prefix with the world as packages from CSW and FOO could be installed at the same time. This would require installations of /usr/sadm/install/scripts/i.cswinetd and /usr/sadm/install/scripts/i.fooinetd
  • This is done by using a custom ~/.garrc. Variables are

PKG_STEM = FOO
PKG_SUBDIRECTORY = foo (results in /opt/foo, /etc/opt/foo and /var/opt/foo)
PKG_DEFAULT_USER = foo
PKG_DEFAULT_GROUP = bar

• This requires changing checkpkg in several ways
  • The maximal length of the catalog must be dynamical as 32 - length(PKG_STEM)
• Cleanbuildable and Buildbot
• Build all with GCC
• Drop 32 bit as the Solaris 11 kernel is also 64 bit only

How to build packages for another world

• Put this in your .garrc (example here for the 'dago' world :-)

ifdef DAGO
PKG_SYSTEM ?= dago    # Prefix for Class Action Scripts
PKG_STEM ?= DAGO    # Stem for packages, like DAGOfoo
PKG_SUBDIRECTORY ?= dago    # Subdirectory, like /etc/opt/dago, /opt/dago and /var/opt/dago
PKG_DEFAULT_USER ?= dago    # Default owner of the files to be installed
PKG_DEFAULT_GROUP ?= dago    # Default group of the files to be installed
endif

• Select the new 'bts' (airport code for Bratislava GAR)

GARTYPE = bts

• Rebuild

mgar DAGO=1 package

Rationale to build with GCC by default

• We want third parties to be able to build e.g. ruby or python modules with GCC.
• Depending on proprietary software carries the risk that the tool will stop being available.
• We were spending a lot of time getting software to build with studio, and in some cases it was not doable in practice.
• You can't mix compilers in C++ code (different name mangling schemes), so we've started /opt/csw/gxx, but this is horrible and we want to stop.

Other options considered

• Stick with Solaris Studio ‒ no, we're constantly running into problems in the current situation.
• Use clang ‒ we haven't managed to build it so far, and we aren't confident that it will work well on SPARC. Feel invited to provide us with evidence to the contrary!

How to build packages for Bratislava?

These instructions are valid for November/December 2012:

• build on the unstable hosts
• make a 'bratislava' branch in subversion, e.g.:

svn cp https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/tree/{trunk,branches/bratislava}

• add the following lines to the recipe:

GARCOMPILER = GNU
COMMON_PKG_DEPENDS =
INCLUDE_COMMONDIRS = 1
CATALOG_RELEASE = bratislava

• checkpkg doesn't know about CSWcommon-less packages, so you will need to add overrides:

CHECKPKG_OVERRIDES_CSWlibcharset1 += bad-location-of-file
CHECKPKG_OVERRIDES_CSWlibcharset1 += disallowed-path

• otherwise proceed as usual
• when the packages are built, use csw-upload-pkg to upload them to bratislava:
  • Note: You need to have fresh GAR sources (svn up) and you must not use /opt/csw/bin/csw-upload-pkg because it doesn't have the new code that allows uploading to bratislava.

path/to/your/mgar/v2/bin/csw-upload-pkg  --catalog-release bratislava <pkg1> [ <pkg2> [ ... ] ]

Sometimes you'll need to think about the order in which to insert the packages. For example libiconv2 doesn't have dependencies, but libiconv-utils does depend on libintl8, so you need to skip libiconv-utils until you upload libintl8.

If you want to get an idea what is the chain of dependencies of your package, visit the QA packages page and see the "Dependency Tree" section. Here's an example: gcc4core. In some cases you'll run into massive dependencies. That's life, we're really building the catalog from scratch.

Bootstrapping into /opt/foo

1. Create a new catalog in the database
2. Install all the necessary tools into /opt/csw (gcc, binutils, coreutils, etc.)
3. Build GCC dependencies, package them as FOOname, add to a catalog, install
   1. All the binaries built with /opt/csw/bin/gcc will have /opt/csw/lib in the search path and will use /opt/csw/lib/libgcc_s.so.1
   2. This will require adding CSWlibgcc-s1 to the foo catalog as well. It's temporary.
4. Build GCC into /opt/foo, add to the catalog, install
   1. This build of foo-GCC will use dependencies that still runtime-link to /opt/csw/lib/libgcc_s.so.1
5. Use /opt/foo/bin/gcc to rebuild all the GCC dependencies again, this time linking to /opt/foo/lib/libgcc_s.so.1
   1. Now foo-GCC uses dependencies that runtime-link to /opt/foo/lib/libgcc_s.so.1
6. Remove CSWlibgcc-s1 from the foo catalog

Proceed as usual. (hopefully!)

Some more ideas (Dago):

• Introduce a BOOTSTRAP_MODE which allows dependencies from FOO to CSW (checkpkg should warn about this if not in bootstrap mode) and has /opt/csw/lib in RPATH appended
• Rebuild these packages without BOOTSTRAP_MODE with deps to FOO only after the basics has been built
• Naming could bee FOO+<pkgname> (being '+' the allowed literal plus)

Known issues

• We don't have a good way to manage the build files, e.g. share common bits of unstable vs bratislava builds. Changes in GAR will be necessary.
• checkpkg doesn't know that CSWcommon is not necessary and needs to be updated
• cswclassutils needs to be adjustable, but the Makefile uses dynamic evaluation which would rely on PKG_STEM being set early, but .garrc is read at the end of the Makefile which is too late.