I don't think I've seen this in previous email threads,
[apologies in advance if it was, please send pointer].
But I have started to wonder if part of the variant architecture
takes into account different 'language release levels' when
it comes to packaging, and if so, what variants should we
be using.
The situation I'm asking about is python related, but the problem
applies to many other languages and subsystems such as php/drupal.
Currently, we seem to be shipping multiple packages of the same
thing, simply because the base release level of the language interpreter
changes.
For instance:
SUNWpython24-cssutils 0.5.11,5.11-0.124:20090925T220158Z
SUNWpython25-cssutils 0.5.11,5.11-0.124:20090925T220204Z
SUNWpython26-cssutils 0.5.11,5.11-0.124:20090925T220222Z
which, presumably, is the same base cssutils python package
reconstituted for the three different python releases currently
being shipped.
I believe that it might be better to use variants in IPS,
that denote that some files should be installed based on which
interpreter is in the system and other files not installed.
I'm theorizing that perhaps each interpreter should be packaged
separately, and perhaps the variant should be activated based on
which package(s) have been installed?
My questions are: Has such a thing been considered?
Can I currently create a single 'developer/python/py' package,
(py.test and pylib: advanced testing tool and networking lib)
that contains all three install variations of the same bits,
so that someone could install the package and get all the
appropriate bits, depending on which interpretor(s) they
currently have installed?
If so, what variants should be used, and how should they be used to
get this result?
If not, is this inside or outside the scope of variants?
Should we keep producing pythonXX-YYY, [and similar] and style
packages in IPS?
Getting more complex, how do we handle something like drupal:
Where we currently use current php5.2.6 but there is a newer php5.2.11
and three active variants of drupal [5, 6, 7], plus themes,
extensions, etc. each at their own release level, you could get
into situations such as:
web/php526-drupal5/theme/zen/nista
...
or maybe:
web/php526/drupal6/theme/zen/nista
web/php5211/drupal7/theme/zen/nista
...
but, I believe a package name similar to this would be preferable:
web/drupal/theme/zen/nista
where IPS 'just figures it out'.
Thanks in advance,
Doug.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
