[arch-projects] Proposal for additional gcc packages

Jason Chu jason at archlinux.org
Tue Aug 24 21:09:00 EDT 2004

> Well, would including the additional languages in the default GCC be
> that big of a deal? How much size would it add? What exact problems
> would crop up?

gcc-java is an extra 52 meg (uncompressed) and gcc-f77 9 meg.  Compressed
it's only 15 meg and 4 meg.

There are problems with build dependent libraries.  I don't know if they
are actual problems, but if gcc-f77 depended on something to build, you'd
have to have a gcc "bootstrap" package anyway, for building base and
everything /before/ building the "real" gcc package.

I'm pretty sure that gcc-java will/can interact somehow with gnuclasspath,
if that became a dep it'd have to be in base, which isn't going to happen.
But people who are using gcc-java probably want the benefits of
gnuclasspath so it would be logical to have it as a dep.

> I'm under the opinion that if there's no serious drawbacks, the
> languages should just be added to the default package. Simply include
> the languages that there is a demand for. In this case, Java and F77 are
> in demand. 

There are arguments against cramming a lot of other languages into an
already working gcc package that I can't remember right now.  Judd would be
better explaining that one.

> It seems having one GCC package actually follows Arch's philosophy
> better. Just like we don't separate Python and Python-tk. We choose the
> best options (in this case, languages). Another example where we choose
> one "big" package is with -dev libraries.

Python is slightly different, but you do have something of a point there.

The example of a "big" package being -dev was only recently and only
because no one wanted to update a swath of -dev packages for xfce4.

> While having these "gcc plugin" packages definitely has the "nifty"
> factor, one big package seems a bit more practical on the surface. Like
> I said, I don't know what exact problems there are. 

I blame gcc's build system actually.  It'd be much cooler if I could say,
"get the config from the already installed gcc package and build this
language using that".  I looked and couldn't find a way to do it.

> Also, like you said, if the GCC package gets upgraded before the gcc
> plugins, pacman will bitch. This seems like it's adding even more work,
> and if these are in Extra, it kind of messes with the CURRENT
> independence Judd is trying to have. With one package, everything gets
> upgraded at once, or nothing gets upgraded until it's all working.

This does not break the current independence.  Things from extra are
allowed to depend on things from current, just not the other way around.
You could install the normal gcc package without any of these extras, but
you couldn't install the extras without the normal gcc package.


If you understand, things are just as they are.  If you do not understand,
things are just as they are.

My old gpg key expired, the new one is available from keyservers.  I was
stupid enough not to realize this before it was too late, so I am not
able to sign my new key with my old key.  If this assurance isn't enough,
please contact me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-projects/attachments/20040824/53b9b1a4/attachment.pgp>

More information about the arch-projects mailing list