[csw-devel] SF.net SVN: opencsw:[398] catalog_signatures/catalog_gpg

[Ben Walton]

Excerpts from Maciej Bliziński's message of Thu Jul 21 18:06:12 -0400 2011:

Hi Maciej,

> We need to arrange a place in the source code tree where we would
> keep shared data in a portable format. Ideally, something that can
> be processed in shell as well as in higher level languages. I was
> thinking about gar/v2/etc or gar/v2/share (if it exists) as the

This is good, but for the code in question, we're talking about a
separate repository (opencsw / gar).  That makes it a bit awkward to
share initially.


> place for these data. We would also need to think where to put these
> files in the filesystem hierarchy when creating packages with gar
> and friends. For this purpose, I would suggest
> /opt/csw/share/opencsw.

I think it's configuration data so it should go in
/etc/opt/csw/catalogs/constants.conf (or similar).  This file could be
stored in svn and checked out/updated on every machine that consumes
it via some chunk of code.

> 1. Keep the data in a simple text format so that it is easy to read
> the right bit of data in shell

I prefer this approach overall, but it only works if we can represent
all data structures in a language neutral format.  It would eliminate
a few things like programmatically generated values, but I think
that's ok (and likely good).

> 2. Keep the data in json and provide a shell utility that prints the
> requested piece of data to stdout.

This would work too, but has the overhead of requiring both a utility
script and possible non-default language libraries for the consuming
programs.  It is quite agnostic though and would allow more
flexibility in what is stored.

In the ruby code to generate the atom feeds, I use arrays to hold:

* physical architectures
* architectures (physical + all)
* releases

The new constants file would need a catalogs array (unstable, current,
etc).

So far, these could all be very easily handled with generic shell
language that could also be parsed by both ruby and python.
Unfortunately, it wouldn't be valid perl.

We could define constants.{sh,rb,py,pl} though and with only a single
place to update all of the versions, it wouldn't be that much
maintenance.

I'm happy to go down this path as it is repeated code everywhere.  I
suggest that we keep these files in the opencsw repo which is where
non package stuff goes.  We can then have all of the tools converted
to require the language specific (if that's the route) file in the
defined location.

Sound good?

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302