Adriaan de Groot wrote:
> On Wednesday 22 April 2009 23:57:08 Stefan Teleman wrote:
>> Adriaan de Groot wrote:
>>> Extra files in the plist indicate a bug in the spec -- they should be
>>> completely deterministic on supported platforms.
>> Before we get to deep into the completely deterministic aspect of the
>> spec files, the spec file for stdcxx at bionicmutton is very badly
>> broken, and has been very badly broken for several months now.
>
> This is unrelated to rebuild-after-fixing-plist, isn't it? What does the
> determinism of the specfiles have to do with the rest of your comment? Are
> you
> saying that the specfiles should *not* be deterministic and should use
> wildcard plists so that the packages contain whatever options were
> automatically detected?
I am saying that before we delve into this wonderful fanciness of
deterministic spec files, we might want to make certain that said spec
files actually build and install the component they are intended to
build and install. Which, in stdcxx's case wasn't happening, as of
yesterday.
> Anyway, those are secondary issues. Help me out here on the stdcxx thing,
> because I have trouble interpreting "badly broken" in a way that can make me
> fix things. Is "several months" four weeks, eight weeks, twelve or more?
> Perhaps you can give me a revision number (from mercurial, so the long hex ID
> would be best, "hg head | grep changeset" will do). The specfiles are
> supposed
> to run the same scripts that you have created in Dude, with the same flags.
> "Supposed to" - I may have missed an update in Dude, that's for sure. So some
> more detail about what's broken would be helpful.
1. %{_includedir}/stdcxx/locale is missing from the spec file, and
this causes a packaging error. This header file is part of the C++
Standard. I'm not even sure how anything locale-related would work if
<locale> is missing from the stdcxx installation.
2. Back in January, i pushed a patch in cvsdude to remove the
installation of stdcxx's <tr1/stdint.h>, because we want to use the
Solaris/Nevada/OpenSolaris /usr/include/stdint.h [ included by
<tr1/cstdint> ]. The spec file at bionicmutton still wants to install
stdcxx's <tr1/stdint.h>, although this file is no longer being
installed. This is a second source of packaging failure.
Evidently, all this has been happening because of the creation of a
second source code repository which was not being kept in sync with
the main source code repository, and because *none* of us knew that
our source code repositories had now been split between two different
locations, with different SCM software, and unaware of each other's
changes.
I am talking about FOSSstdcxx.spec src_rev 4 at bionicmutton.
Which brings up a third point: what do these src_rev numbers mean ?
There were three of us in #kde-solaris yesterday trying to figure out
what these src_rev numbers mean, and none of us could come up with a
plausible hypothesis, let alone an explanation.
I pushed fixes for FOSSstdcxx.spec yesterday, in cvsdude, in the SPECS
directory, but that directory is now gone.
Here we are, patching spec files by means of email descriptions in
essay format.
--Stefan
--
Stefan Teleman
Sun Microsystems, Inc.
stefan.teleman at Sun.COM
