[arch-projects] Proposal for additional gcc packages
This is something I've been kicking around for a bit. Having other gcc packages like gcc-f77 and gcc-java would be helpful, 1) to shut people like this up (http://bbs.archlinux.org/viewtopic.php?t=6376) and 2) for people who actually need a f77 compiler (or a java compiler or whatever). My idea goes something like this. Don't touch the gcc package. Instead, make a similar PKGBUILD that just compiles the additional languages. Compare that package's file list to the gcc package's file list and cull out the duplicates. As long as the existing gcc package doesn't store a list of compiled languages, then it should work. I've already built a gcc-f77 package based around this idea and gcc-java will soon follow. I do lack the skills to properly test the gcc-f77 package, though it is available here: http://xentac.net/~jchu/gcc-f77-3.4.1-2.pkg.tar.gz The way I've explained it so far, you may be wondering about gcc upgrades. The gcc-f77 package depends on gcc=$pkgver, so if gcc is upgraded before gcc-f77, pacman will complain. In that way, you'll never have conflicting package versions installed at the same time. The only drawback to this approach that I've found is that you compile gcc multiple times. The only solution to that is make a method to build multiple packages from one PKGBUILD. This goes against the KISS design philosophy and would break a lot of stuff for only a few benefits (a few packages). Jason -- 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.
On Tue, 24 Aug 2004 15:54:01 -0700, Jason Chu <jason@archlinux.org> wrote:
This is something I've been kicking around for a bit. Having other gcc packages like gcc-f77 and gcc-java would be helpful, 1) to shut people like this up (http://bbs.archlinux.org/viewtopic.php?t=6376) and 2) for people who actually need a f77 compiler (or a java compiler or whatever).
My idea goes something like this. Don't touch the gcc package. Instead, make a similar PKGBUILD that just compiles the additional languages. Compare that package's file list to the gcc package's file list and cull out the duplicates.
As long as the existing gcc package doesn't store a list of compiled languages, then it should work.
I've already built a gcc-f77 package based around this idea and gcc-java will soon follow. I do lack the skills to properly test the gcc-f77 package, though it is available here: http://xentac.net/~jchu/gcc-f77-3.4.1-2.pkg.tar.gz
The way I've explained it so far, you may be wondering about gcc upgrades. The gcc-f77 package depends on gcc=$pkgver, so if gcc is upgraded before gcc-f77, pacman will complain. In that way, you'll never have conflicting package versions installed at the same time.
The only drawback to this approach that I've found is that you compile gcc multiple times. The only solution to that is make a method to build multiple packages from one PKGBUILD. This goes against the KISS design philosophy and would break a lot of stuff for only a few benefits (a few packages).
Jason
-- 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.
I think this is one of those situations where the idea of adding split-off functionality to makepkg (akin to what Debian and many other distros do) would come in quite handy. That way you could have one PKGBUILD which built all of the gcc languages, and then split it off into gcc, gcc-f77, gcj, etc. AFAIK someone actually made a patch to makepkg a while back that added this functionality; it's a pretty trivial change. -- Michael Baehr - Arch Linux GNUstep Geek
I think this is one of those situations where the idea of adding split-off functionality to makepkg (akin to what Debian and many other distros do) would come in quite handy. That way you could have one PKGBUILD which built all of the gcc languages, and then split it off into gcc, gcc-f77, gcj, etc. AFAIK someone actually made a patch to makepkg a while back that added this functionality; it's a pretty trivial change.
It's not a trivial change; he only completed the easy part of the equation and not perfectly either. Makepkg -b wouldn't work, because it reads the PKGBUILD to find the package name to build deps. Gensync wouldn't work because it assumes you have one package per PKGBUILD. In that way, updatesync wouldn't work either. All the main archlinux.org scripts would have to be reworked to support multiple packages from a single PKGBUILD. As I said, it's a lot of work to do it when you only gain one or two extra packages. I'm trying to solve those one or two cases instead of redesigning everything to work around the paradigm shift. Jason -- 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.
On Tue, 2004-08-24 at 17:54, Jason Chu wrote:
This is something I've been kicking around for a bit. Having other gcc packages like gcc-f77 and gcc-java would be helpful, 1) to shut people like this up (http://bbs.archlinux.org/viewtopic.php?t=6376) and 2) for people who actually need a f77 compiler (or a java compiler or whatever).
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? 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. 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. 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. 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. Just a thought. Ben -- Now remember, we can't ALL sign with an X
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. Jason -- 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.
On Tue, 2004-08-24 at 20:09, Jason Chu wrote:
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.
Your other points are technical, which I have no knowledge on, so I will only comment on this. I was referring to including the development headers in packages. In most distros, there are things like "gtk2" and "gtk2-devel". We include both in one package. At least, I think you misunderstood. I'm pretty sure this has been going on long before XFCE4. Ben -- Now remember, we can't ALL sign with an X
On Tue, 24 Aug 2004 21:18:45 -0500, Ben Mazer <ben@benmazer.net> wrote:
On Tue, 2004-08-24 at 20:09, Jason Chu wrote:
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.
Your other points are technical, which I have no knowledge on, so I will only comment on this.
I was referring to including the development headers in packages. In most distros, there are things like "gtk2" and "gtk2-devel". We include both in one package. At least, I think you misunderstood. I'm pretty sure this has been going on long before XFCE4.
I personally agree with Arch's practice on this. I can see why separating out the -devel packages is useful for distros that have much more of an "end-user" and not a "developer" focus, but as far as the average Arch user is concerned, it's much more useful to always have the development headers and libraries included with a package. -- Michael Baehr - Arch Linux GNUstep Geek
participants (3)
-
Ben Mazer
-
Jason Chu
-
Michael Baehr