Re: Bug#233389: Inefficient packaging of arch independent data in package libasis-3.15p-1-dev
libasis-3.15p-1-dev exists only on two architectures: i386 and powerpc.
The *.adb and *.ads files under /usr/share/ada/adainclude/asis are
indeed architecture-independent. They are the Ada equivalent of C
"include files". However, they are only useful if package `gnat' is
also installed; gnat exists only on i386, powerpc and sparc.
The reason why they are in /usr/share/ada/adainclude instead of
/usr/include is to conform with Florian Weimer's proposed GNU Ada
I have experimented with splitting the package and here is what I get:
Before split: libasis-3.15p-1-dev_3.15p-4_i386.deb : 3144k
libasis-3.15p-1-dev_3.15p-4_sparc.deb : 3624k
After split: libasis-3.15p-1-dev_3.15p-5_i386.deb : 1862k
libasis-3.15p-1-dev_3.15p-5_sparc.deb : 2390k (est.)
libasis-3.15p-1-dev-common_3.15p-5_all.deb : 1234k
On mirrors that contain both i386 and sparc, this saves roughly 1234k.
However, there probably are mirrors that do not have either i386 or
sparc; for example, mirrors for hppa only. These mirrors would have
to carry an extra package, which would be useless since `gnat' is not
available for these architectures.
Is it really worth it?
The proper solution would be to make it so that this package exists
only for i386 and sparc, but is shared between them. Is this
possible? From what I understand, it seems not, so my inclination is
to tag the bug as wontfix. However I would like to have consensus on
Note that I maintain several other packages which also have files
under /usr/share/ada/adainclude; these are libcharles0-dev,
libflorist-3.15p-1-dev, gnat-glade, gnade-dev, libgtkada2-dev (see
also #233397), libopentoken-dev, and libxmlada1-dev. Most of these
other packages are for i386, powerpc and sparc. I would like to split
them all, or none of them, in a consistent way. On my machine with
all of these packages installed, I have:
$ du -sk /usr/share/ada/adainclude
$ find /usr/share/ada/adainclude -type f | wc -l
If you respond, please do _not_ quote the above message, and CC
firstname.lastname@example.org. I am not subscribed to debian-devel, but I
monitor the bug.