[Apt-Rpm] 0.5.15lorg3.93 Solaris build issue

[Panu Matilainen]

Sorry for being a little late for the party... :)

On Wed, 19 Sep 2007, David Halik wrote:
> Awesome Anders, thank you so much. That pointed me in the right
> direction and actually I found what was the main issue with suncc. First
> off, this was what was ripping the compiler up. I'm not that great with
> c++, but that definitely looked like a typo and it completes now.
>
> diff -ruN apt-0.5.15lorg3.93/apt-pkg/rpm/rpmpackagedata.h
> apt-0.5.15lorg3.93.new/apt-pkg/rpm/rpmpackagedata.h
> --- apt-0.5.15lorg3.93/apt-pkg/rpm/rpmpackagedata.h     2007-05-14
> 05:01:55.000000000 -0400
> +++ apt-0.5.15lorg3.93.new/apt-pkg/rpm/rpmpackagedata.h 2007-09-19
> 15:09:01.633396000 -0400
> @@ -39,7 +39,7 @@
>    map<string,vector<string>*> FakeProvides;
>    map<string,int> IgnorePackages;
>    map<string,int> DuplicatedPackages;
> -   map<string,bool> > CompatArch;
> +   map<string,bool> CompatArch;
>    typedef map<string,pkgCache::VerIterator> VerMapValueType;
>    typedef map<unsigned long,VerMapValueType> VerMapType;
>    typedef map<const char*,int,cstr_lt_pred> ArchScoresType;

Yup, a silly typo that hasn't been caught due to my environments always 
using gnu hash map. Applied...

[...]
> "../include/apt-pkg/pkgcachegen.h", line 62: Error: Multiple declaration
> for Pkg.
>
> I pulled the code out and it does look to be defined twice. I'm not sure
> how I'm going to get around this though, if its actually coded this way
> against c++ standards then there must be a reason. I'm guessing what I'm
> seeing here is the older suncc being extremely strict with its rules :/
> I'm interested to see if gcc trips up on this same error.
>
> // CNC:2003-02-27 - We need this in rpmListParser.
> bool NewPackage(pkgCache::PkgIterator &Pkg,string Pkg);

Just a silly typo/thinko, funny that gcc doesn't mind... anyway, fixed too 
now.

I'm not applying the rpm5.org hacks at the moment, not because of 
"political" issues but simply because they're nasty hacks to expose 
internals that have been purposefully hidden from the API. Some proper way 
to deal with them is needed, the rpm support code is going to require 
large reorgs anyway in not-so-far-future.

That leaves the unsetenv()/putenv() thingy... It seems to be an ugly mess 
as far as portability goes (from autoconf manual):

---
Posix prefers setenv to putenv; among other things, putenv is not required 
of all Posix implementations, but setenv is.

Posix specifies that putenv puts the given string directly in environ, but 
some systems make a copy of it instead (e.g., glibc 2.0, or BSD). And when 
a copy is made, unsetenv might not free it, causing a memory leak (e.g., 
FreeBSD 4).

On some systems putenv ("FOO") removes `FOO' from the environment, but 
this is not standard usage and it dumps core on some systems (e.g., AIX).

On MinGW, a call putenv ("FOO=") removes `FOO' from the environment, 
rather than inserting it with an empty value.
---

Ugh... anybody using apt-rpm on AIX? ;)

 	- Panu -