Has anyone looked at the possibility of having a shared CD or two between the x86_64 and i386 installs?
There's 412300KiB of noarch packages which are present in both x86_64 and i386, and 436108KiB of i[36]86 packages in the x86_64 tree.
If a package ordering can be found which allows a bunch of those to go onto a CD which is shared between x86_64 and i386 installations, we get to lose a CD out of the set without running around like headless chickens trying to excise useful packages to make the i386 tree smaller.
David Woodhouse dwmw2@infradead.org:
Has anyone looked at the possibility of having a shared CD or two between the x86_64 and i386 installs?
There's 412300KiB of noarch packages which are present in both x86_64 and i386, and 436108KiB of i[36]86 packages in the x86_64 tree.
If a package ordering can be found which allows a bunch of those to go onto a CD which is shared between x86_64 and i386 installations, we get to lose a CD out of the set without running around like headless chickens trying to excise useful packages to make the i386 tree smaller.
As an Opteron user, I strongly support this suggestion.
On Feb 24, 2005, David Woodhouse dwmw2@infradead.org wrote:
Has anyone looked at the possibility of having a shared CD or two between the x86_64 and i386 installs?
As good as an idea as it might sound, it poses some interesting infrastructure problems, and it doesn't address the most important issue in my understanding.
As for infrastructure, it requires the entire CD set to be regarded as part of the same distro spin, as opposed to having each arch being spun separately as it stands now. This is why you see different SRPMS isos for x86_64 and i386, for example, and why fedora-release has a different build number between them. Yes, this would be great to fix, and would further reduce the amount of space mirrors get to carry. In fact, fixing this is probably *far* more important that cutting out half a CD from the i386 binary set.
As for the most important issue, which is the i386 CD count, it won't make any difference: CD distributors will still have to print 5 instead of 4 CDs to offer the complete FC4/i386.
Not that I find this all that important, personally, nor that I agree with the current pursuit of such goal, but I thought I'd point out that it unfortunately fails to help.
David Woodhouse (dwmw2@infradead.org) said:
Has anyone looked at the possibility of having a shared CD or two between the x86_64 and i386 installs?
Due to dependency ordering of libraries, you'd almost certainly need to do *more* CD swaps if you went this way. (Infrastructure issues aside.)
Bill
On Thu, 2005-02-24 at 15:01 -0500, Bill Nottingham wrote:
Due to dependency ordering of libraries, you'd almost certainly need to do *more* CD swaps if you went this way.
Why so?
The i386 packages available on the x86_64 installation are a set with complete dependency closure, surely? So they could reasonably be first in the i386 pkgorder, and hence on the i386 CD 1?
If we also include as many of the noarch packages as we can on i386 CD 1, could we not have a reasonable expectation of fitting that into the x86_64 pkgorder -- as a block which is a fairly independent set?
Or does anaconda actually have to install both packages in an {i386,x86_64} multilib set simultaneously?
On Thu, Feb 24, 2005 at 01:13:35PM +0000, David Woodhouse wrote:
Has anyone looked at the possibility of having a shared CD or two between the x86_64 and i386 installs?
There's 412300KiB of noarch packages which are present in both x86_64 and i386, and 436108KiB of i[36]86 packages in the x86_64 tree.
and you can probably double this number if some packages would cast out their noarch stuff disguised as arch-dependend.
For example almost all of tetex is noarch in essence (the whole texmf tree), which already adds up to 150-200M.
Splitting out the texmf tree is a bit painful, it requires two src.rpms.
If a package ordering can be found which allows a bunch of those to go onto a CD which is shared between x86_64 and i386 installations, we get to lose a CD out of the set without running around like headless chickens trying to excise useful packages to make the i386 tree smaller.
On Thu, 2005-02-24 at 21:18 +0100, Axel Thimm wrote:
and you can probably double this number if some packages would cast out their noarch stuff disguised as arch-dependend.
For example almost all of tetex is noarch in essence (the whole texmf tree), which already adds up to 150-200M.
Splitting out the texmf tree is a bit painful, it requires two src.rpms.
The kernel manages to build both arch-specific and noarch rpms from the same source. Why couldn't tetex?
On Thu, Feb 24, 2005 at 08:22:50PM +0000, David Woodhouse wrote:
On Thu, 2005-02-24 at 21:18 +0100, Axel Thimm wrote:
and you can probably double this number if some packages would cast out their noarch stuff disguised as arch-dependend.
For example almost all of tetex is noarch in essence (the whole texmf tree), which already adds up to 150-200M.
Splitting out the texmf tree is a bit painful, it requires two src.rpms.
The kernel manages to build both arch-specific and noarch rpms from the same source. Why couldn't tetex?
It could if called multiple times like the kernel is called. But the kernel package and support calls on creating the noarch parts show that this is not trivial for the users, no matter how well documented in the release notes.
Anyway the potential is there, but OTOH that would save on the total number of CDs (by having common CDs), not on the number of CDs required per platform (don't know which is the harder request).
devel@lists.stg.fedoraproject.org
-
Alexandre Oliva -
Axel Thimm -
Bill Nottingham -
David Woodhouse -
Eric S. Raymond -
Jeremy Katz