[RFC] GCC-4 new packaging.

[Dave Korn]

Dave Korn wrote:

>   I'm about ready to release a new compiler package.  This is going to mean a
> whole bunch of new packages and one obsoletion, and I was hoping I could get a
> hand proof-reading the setup hints and any comments anyone has on packaging,
> names and categories.

  Thanks for all the comments, which I'll summarize in one response.

Yaakov (Cygwin/X) wrote:

> The gcc4- and -runtime are just confusing; these should be just libgcc1,
> libgomp1, etc.  Remember that these will be runtime dependencies for
> other packages, and these names are consistent with (most) other runtime
> libraries, and match those in Debian.

  I think I just blindly assumed all the cygport package array entries had to
begin with PN but on re-RTFM-ing after my second cup of coffee, I see that's
not remotely the case, so I'll certainly do that.

>> gcc4-java-runtime-config-4.3.2-2
> I would call this libgcj-common, as in Debian.

  Will do.

> What is the reason for separating gcc and gcc-core?  Yes, I know that
> gcc-3.4 did this also, but I don't remember the rationale.

  I think in 3.x it was to do with some kind of historical legacy thing.  I've
adopted the same nomenclature and split in 4.x, but not for the same reason.

  In 4.x I figure that the most common combination of languages that people
want will be "C and C++" by a hundred to one or more, so I decided that I'd
make it work so that the plain vanilla "gcc" package was a shortcut for "C and
C++".  Not wanting to deny anyone the option of installing C-only implied that
I had to split it out into some separate package, so I chose the same name as
the 3.x version used.

  It's really just about user convenience and least surprise: a lot of end
users would like to just install a package called "GCC" and be able to compile
downloaded sources without having to think about what languages are involved.
 So unless anyone has major objections or can foresee any serious problems,
I'm going to continue packaging it this way.

> I'm tempted to suggest a libstdc++6-devel (yes, versioned, because the
> includes and link libs are in versioned directories), for C++ libtool
> libraries that provide a C interface (and hence may be built against
> with just gcc).

  Interesting thought.  I'm not entirely happy with encouraging the use of the
wrong driver.

> Please create a separate libffi-devel with ffi*.h (which I don't see
> listed here) and libffi.*, as there are C packages that use libffi as well.

  Okeydokey, can do.

> BTW, why is libgij static-only?

  No idea.  Maybe it's supposed to be that way, or maybe something went wrong
in my build, I'll double-check; thanks for spotting it.

> Otherwise looks okay; cygport will tell you if you're missing anything.

  Ta.  I think I've successfully de-forkified the whole local-hacked-cygport
thing now.

> objc.hint: /^req/ s/gcc4-c++/gcc4-g++/

  Again, ta!  That's just the kind of detail that your eyes stop seeing after
a while :)

> I know there was some discussion about deps on _update-info-dir
> recently, but AFAICS it only makes sense for texinfo to depend on
> _update-info-dir.  It's irrelevant if the package installs .info pages
> if the user doesn't have texinfo to view them!

  ?? But doesn't that mean the info directory page would only get updated
every time there's a new release of texinfo?  I'm really confused here.  I
thought we used the _update-info-dir dependency to save having to add the
postinstall scripts built by prep_gnu_info.sh.  How would "install-info" get
called on the new info files?

> That's my 0.02 (CAD).

  Thanks, eh!

Marco Atzeri wrote:

> is not needed a
> requires:libgcc1

> I suspect a version bump plus a empty tar file

  Marco, I think Yaakov's explanation is right, it looks that way to me.

Reini Urban wrote:

> Those sound suspicious to me.
> Yaakov has the latest libffi5  3.0.8-1 (API 5 with version 3.0.8)
>
> Do you really have only API 4?

  I have .... whatever version of libffi was in the GCC tree at the time 4.3
was branched.  I don't know how closely tied to the particular API the
compiler is.  This means that if I create a libffi-devel package, it could
clash with a cygwin ports installation, and users might get a mismatch (cygwin
ports libffi5 with gcc-4 libffi-devel for libffi4.

  I'm not sure what to do about this yet.  Yaakov, any ideas?

 (My GNAT problems look tractable, btw, exception handling is broken because
something's getting lost in the .initfini and the ctors/dtors tables come up
emty, so no eh data gets registered; this could be related to using static
libgcc with ada and could even be an indication of fundamental problems with
exceptions in static libgcc, so I will investigate it a bunch more).

    cheers,
      DaveK