The time when I will switch the default Ada compiler from gnat-4.3 to gnat-4.4 approaches. I am revisiting gcc-defaults and it seems overly complex to me. I am therefore considering splitting the gnat source package out of gcc-defaults and am looking for reasons why I should not do that.
gcc-defaults should be as complex as necessary and as simple as possible; I feel it fails in this respect by being more complex than necessary: - gnat-x.y is a separate package from gcc-x.y, therefore there is no reason why gnat should be tied with gcc or g++. But the current situation requires that each upload of a new gcc, g++, requires a simultaneous upload of gnat. - As a consequence, gcc-defaults requires labor-intensive maintenance of variables (e.g. REL_NO_441 and friends, REQV_44 and friends, REQV_GNAT, etc). This maintenance and these variables are necessary only because all the defaults are tied together in a single package. I fail to see what higher purpose they serve. The binary gnat package has only one requirement: depend on whichever package gnat-x.y is the default on each supported architecture. Everything else, to me, is line noise. I think that a new source package named gnat could meet the requirement much more directly than gcc-defaults can. A new version of gnat would be necessary only when changing the default Ada compiler or changing the list of supported architectures (per the requirement). I think the dependency and list of architectures can be maintained directly in the control file instead of indirectly in a bunch of variables, without any adverse impact on legibility or maintainability. PS. My reasoning may also apply to gcj, gpc and gdc because they are built separately but here I'm only talking about gnat. The relevant language maintainers can choose to ignore me or follow suit. Any objections? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org