2015-09-29 17:38 Wookey:
+++ Manuel A. Fernandez Montecelo [2015-09-29 12:27 +0100]:
Maybe it would be a good idea to split the architectures, and have one
port for legacy-but-still-sold-or-useful i386 and move the current i386
to only support newer, common-use i686 hardware.
It seems to me that this relates to a similar issue with armel, and
previous consideration of 'partial architectures' for mips (and arm).
[...]
Having a mechanism for 'partial architectures' to keep only the
relevant subset of the archive available for these machines seems like
a good plan, useful for at least i386 and armel, and probably
others. Because a debian arch refers to an ABI, not an ISA-variant,
you can't easily use our existing architectures mechanism to have both
'i386' and 'i686' without breaking some fairly fundamental assumptions.
Being able to have 'partial achitectures' which are actually different
baseline ISAs (586, 686) (armv6, armv7) for one ABI is something that
has been discussed many times, but no-one has ever cared enough to
actually implement it.
This is particularly relevant on mips, where inconsistent ISA changes
over the years mean that make picking one 'base ISA' is very
unsatisfactory, and they would like a way of having alternative ISA
(not ABI) builds of a significant set of packages (anthing where speed
actually matters, so libc, some core things and anything
codec-related, at least). (The rasbian port could have done things
this way and stayed within Debian for example, but it was easier to
derive).
Some details of a proposal for implemnting this are covered in section
2 of https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results
It would need fleshing out some more to actually be complete.
(These ideas could also be applied for packages compiled with special
characteristics, like optimised for multimedia instructions; or
compiled with address sanitiser, undefined behaviour sanitiser, etc --
somebody was talking about this in DebConf, I think that it was
Bálint).
Honest question, not a snarky one; but after reading your e-mail and the
proposal it is still not very clear to me what's the fundamental
underlying difference (or the advantage, in terms of which problems
solves better, and how) between a partial architecture, a full
architecture which possibly doesn't build a [large?] subset of packages
(there are mechanisms like "not-for-us" and "package-arch-specific",
which you probably know better than me), and an "overlay"-like
repository such as experimental or security-updates (although I am aware
that overlays don't get packages to build in the same way as arches, one
has to target them).
If I understand correctly what I read from partial arches, there has to
be a common baseline and baseline has to be the lowest common
denominator, in the case of i386/i686 (or armel/armhf), the baseline has
to be i386 or armel (so you can boot in the baseline, and then enable
the "flavour"/partial-arch more suited to your hardware). And since in
the example of Intel it is widely used and capable hardware, people
could want almost every package. If armel cannot cope with some
packages (e.g. 32-bit arches already having real trouble
compiling/linking some packages), the packages would be put in some
"not-for-us", or simply let to fail, as it probably happens already.
In that case, the amount of compiled packages would be about the same,
the storage about the same, etc. The only thing that we would reuse is
a small set of packages that allow users to start the machine and enable
the "flavour". I don't think that there would be much difference with
having two full architectures?
In the case that it works like an overlay-like repository
("jessie+i686", "jessie/i686" or whatever the convention), one could pin
this repository to take precedence and so install packages from it. It
doesn't work very well if one thinks of unstable/experimental (packages
not being available at the same time), but it does if you imagine using
multiarch already today with stable releases -- you have all packages
there on both arches at the same time. (Ubuntu PPAs and Debian
I-hesitate-to-call-Bikesheds are also supposed to work in this way).
If the amount of packages available is again "almost all", it doesn't
gain much over full ports in terms of CPU usage and storage.
In all cases, I assume that humanpower needed to tend the ports is about
the same.
So, in summary, I don't see these mechanisms as very different in terms
of resources compared to what I learn from partial architectures so far.
The main difference that I see among them is that full ports and overlay
repositories already work and don't need modification to existing
tools/practices; multiarch with compatible ports in the same machine and
overlay repositories and apt-pinning already work today. (Overlays are
probably a less elegant solution for this, but also potentially less
problematic on a day-to-day basis than multiarch -- only one version
would be installed at the same time, less installation conflicts and
packaging bugs and so on).
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
