Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=15227

           Summary: Sorcery should include ARCHITECTURE in cache tarball
                    name
           Product: Sorcery
           Version: Untargetted future release
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: Feature Request
        AssignedTo: sm-sorcery-bugs AT lists.ibiblio.org
        ReportedBy: sandalle AT sourcemage.org


Sorcery should include ARCHITECTURE in cache tarball name.

Currently, for gcc on any x86 machine:
gcc-4.1.1-i686-pc-linux-gnu.tar.bz2

This should instead be more like:
gcc-4.1.1-athlon-xp-pc-linux-gnu.tar.bz2 

Or, to keep the code simpler:
gcc-4.1.1-athlon-xp-i686-pc-linux-gnu.tar.bz2 

Where "athlon-xp" is coming from ARCHITECTURE as defined in
/etc/sorcery/local/config.

The main case for this is when sharing /var/cache/sorcery amongst many
machines, you do not want caches restored to a core2 machine that were built
for an athlon-xp machine, though both are i686. We may want to remove any _32
and similar, unless we go with the second example above (rather than the 
third)
from ARCHITECTURE names (e.g. core2_32).

When using a generic ARCHITECTURE (e.g. x86_64 or i686), we could probably
exclude the ARCHITECTURE flag from the cache tarballs, but it is not required
(and may make the code simpler to not make a distinction).

Example scenario:
machine1: ARCHITECTURE=i686
machine2: ARCHITECTURE=athlon-xp
machine3: ARCHITECTURE=core2_32
machine4: ARCHITECTURE=pentium-m
machine5: ARCHITECTURE=core2 (the only 64-bit machine here)

Currently we'd have the following cache tarballs generated:
machine1: gcc-4.1.1-i686-pc-linux-gnu.tar.bz2
machine2: gcc-4.1.1-i686-pc-linux-gnu.tar.bz2
machine3: gcc-4.1.1-i686-pc-linux-gnu.tar.bz2
machine4: gcc-4.1.1-i686-pc-linux-gnu.tar.bz2
machine5: gcc-4.1.1-x86_64-pc-linux-gnu.tar.bz2

Note that all the x86 machines will be overwriting each others' cache tarballs
with a shared /var/cache/sorcery.

Proposed solution #1: Uses just ARCHITECTURE, replacing the generic field
machine1: gcc-4.1.1-i686-pc-linux-gnu.tar.bz2
machine2: gcc-4.1.1-athlon-xp-pc-linux-gnu.tar.bz2
machine3: gcc-4.1.1-core2_32-pc-linux-gnu.tar.bz2
machine4: gcc-4.1.1-pentium-m-pc-linux-gnu.tar.bz2
machine5: gcc-4.1.1-core2-pc-linux-gnu.tar.bz2

Proposed solution #2: Uses both ARCHITECTURE (minus _32 and such) and BUILD
machine1: gcc-4.1.1-i686-i686-pc-linux-gnu.tar.bz2
machine2: gcc-4.1.1-athlon-i686-xp-pc-linux-gnu.tar.bz2
machine3: gcc-4.1.1-core2-i686-pc-linux-gnu.tar.bz2
machine4: gcc-4.1.1-pentium-m-i686-pc-linux-gnu.tar.bz2
machine5: gcc-4.1.1-core2-x86_64-pc-linux-gnu.tar.bz2

Proposed solution #3: Remove redundancy from generic ARCHITECTURES
machine1: gcc-4.1.1-i686-pc-linux-gnu.tar.bz2
machine2: gcc-4.1.1-athlon-i686-xp-pc-linux-gnu.tar.bz2
machine3: gcc-4.1.1-core2-i686-pc-linux-gnu.tar.bz2
machine4: gcc-4.1.1-pentium-m-i686-pc-linux-gnu.tar.bz2
machine5: gcc-4.1.1-core2-x86_64-pc-linux-gnu.tar.bz2
(note if machine5 used x86_64 instead, it would look like machine1 with
s/i686/x86_64/).

I prefer solution #1, mostly to keep the cache name shorter and, hopefully, 
not
too confusing.

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.