removal of gnatgcc, -dev packages with a version
Hello.
Intrusive changes are on their way.
Are there any objection?
The usr/bin/gnatgcc symbolic link has caused lots of maintenance
issues, for arguable benefit, and even confusion in rare occasions.
It will eventually be removed.
For now, it will be replaced with a script displaying the following
text before running gcc-MAJOR.
Warning: gnatgcc is deprecated. Please use gcc-MAJOR where MAJOR is
# gnatmake --version | sed 's/.* \([0-9]\+\).*/\1/;q')
For GPR projects, this should be sufficient:
# gprconfig --batch --config=Ada --config=C,,,,MAJOR
Ada -dev packages will stop carrying a version, but provide a virtual
package carrying a hash.
If all goes well, this should be transparent for end users, trivial
for maintainers of programs, but simplify a lot the packaging of
libraries and prevent a whole family of errors.
* the ALI version automatically changes without human intervention
* no passage through NEW (at least, not because of .ali changes)
* libgnat *does* carry an ALI version, like any library
* when a library changes, reverse dependencies only require a
no-source-change rebuild (like for new SOnames)
Details at https://wiki.debian.org/LanguageVersionedDevPackages
By the way, I would also like opinions about obscure parts of the GNAT
packaging.
* README.gnat is installed into gnatbase only wthe with_separate_gnat
is active.
It should probaly move to the gnat-BV package (independently of
with_separate_gnat).
As far as I understand/know, with_separate_gnat allows to build GNAT
from a gnat-source binary package. This has not been necessary for
ten years.
Should we disable with_separate_gnat?
What is the difference with ifeq ($(PKGSOURCE),gnat-$(BASE_VERSION))?
(rules.conf does both tests in a row)
* the acats-killer script starts with a header explaining that it
solves an issue on ia64.
This architecture has been removed in 2018.
Is it safe to remove the script?
Thanks.
Reply to: