Bug 340501 - FutureFeature -- Restructuring repositories into more suitable formats
FutureFeature -- Restructuring repositories into more suitable formats
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-19 16:25 EDT by Frederik Hertzum
Modified: 2014-01-21 17:59 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-06 22:35:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frederik Hertzum 2007-10-19 16:25:03 EDT
Given that no 32 bits components from the x86_64 repositories are different from
the 32 bit repositories (i.e., a package from the 32 bit repository will be
always be the same as the same 32 bit package from a repository ment for 64 bit
installations) there is no reason to have two repositories for where one if a
superset of the other.

I propose that all repositories be restructured as follows:
bin-<basearch>-<bitsize>
lib-<basearch>-<bitsize>
bin-noarch
lib-noarch
data

Where basearch is currently one of x86 or ppc and bitsize is either 32 or 64 --
this allows the combinations of *-x86-32, *-x86-64, *-ppc-32 and *-ppc-64.
Should ARM ever be standardized in Fedora it would become *-ARM-*.

The *-<arch>-<bitsize> repositories would contain only the packages specific to
them. That means that the 64 bit repositories should not contain any 32 bit
packages and vice versa. It also means that noarch repositories should be made
available, for the things that are non-platform specific.

Why not just use a bin/lib-<arch> instead of including a bitsize? I like to
think that it makes it more apparent that some things don't match and some thing
do match. For example, if you have a ppc somewhere, but your basearch is x86,
it's going to be pretty clear that something is wrong. After all, everything
else says x86.
The reason for a bin/lib split is a userinterface thing. Mostly people don't
search for libraries and if a person knows she is only looking for an end user
application (or plugin for one) then searching and parsing the content of a lib
repository is work that doesn't need to be done -- including matches from these
will likely only make it more confusing. The split is the best way (as far as I
can see) to enable this elegantly.

The *noarch" repositories should contain anything which is run on a virtual
machine of through an interpreter, unaltered on all archs.

The data repository should contain data files which are shared between archs --
it may need a split depending on future addition of architectures (due to
endianness problems).

The primary reason why I think this is a good thing is that currently there are
packages in the 32 bit x86 repository which are useful for 64 bit installations
but haven't been made available on x86_64. This first of all removes all
duplicate packages and (hopefully) allows easier maintenance of the repositories.

It may be a good idea to include a tag which sets which basearchs and/or bitsize
it installs on, if required.
Comment 1 Seth Vidal 2007-12-06 22:35:02 EST
1. this would be a createrepo bug if anything
2. even if it were filed against createrepo I still wouldn't want this to happen
to repositories.

Closing wontfix.
Comment 2 Frederik Hertzum 2007-12-07 02:21:49 EST
1. Noted.
2. Why not?
Comment 3 Florian Festi 2007-12-07 04:33:23 EST
Splitting up into bin, lib and data requires breaking up the packages to much
smaller pieces. This has several drawbacks and will require huge changes to
rpmbuild, the build system and several other parts.

What I could imagine to be worth looking at is having pure repositories per arch
and using the i386 and x86_64 repository for x86_64. May be it is even worth
thinking about an noarch repository. But all this is not likely to happen in the
near future. Especially as it requires much more meta data to for the multilib
arches to keep track of.
Comment 4 Frederik Hertzum 2007-12-07 16:40:03 EST
Thanks for the explanation -- in the light of those arguments, I agree. I still
like the idea of pure repositories though.

Note You need to log in before you can comment on or make changes to this bug.