[Octave-bug-tracker] [bug #48710] normalize core and package architecture-dependent installation directories

[Mike Miller]

Update of bug #48710 (project octave):

                Severity:              3 - Normal => 1 - Wish               
              Item Group:        Incorrect Result => Feature Request        
                  Status:               Need Info => Postponed              
                 Release:                   4.0.3 => dev                    
                 Summary: changed config.guess helper script makes installed
packages unusable => normalize core and package architecture-dependent
installation directories

    _______________________________________________________

Follow-up Comment #4:

Ok I'm retitling this appropriately, I think it makes sense for a future
release to make the directory components that Octave installs into and uses to
be a little more robust and depend only on the minimal information needed to
separate one incompatible build from another.

I am motivated to work on this, but it will have to wait until the next
release cycle.

Here is a list of installation directory components from the Debian builds of
octave for all supported architectures. I chose the same "oct" directory for
all builds. The path contains both the Debian multiarch tuple (after
"/usr/lib") and the GNU host triplet (after "4.0.3/oct")



/usr/lib/  aarch64-linux-gnu        /octave/4.0.3/oct/ 
aarch64-unknown-linux-gnu
/usr/lib/  alpha-linux-gnu          /octave/4.0.3/oct/ 
alpha-unknown-linux-gnu
/usr/lib/  arm-linux-gnueabi        /octave/4.0.3/oct/ 
arm-unknown-linux-gnueabi
/usr/lib/  arm-linux-gnueabihf      /octave/4.0.3/oct/ 
arm-unknown-linux-gnueabihf
/usr/lib/  hppa-linux-gnu           /octave/4.0.3/oct/ 
hppa-unknown-linux-gnu
/usr/lib/  i386-gnu                 /octave/4.0.3/oct/  i686-pc-gnu
/usr/lib/  i386-kfreebsd-gnu        /octave/4.0.3/oct/  i686-pc-kfreebsd-gnu
/usr/lib/  i386-linux-gnu           /octave/4.0.3/oct/  i686-pc-linux-gnu
/usr/lib/  mips-linux-gnu           /octave/4.0.3/oct/ 
mips-unknown-linux-gnu
/usr/lib/  mips64el-linux-gnuabi64  /octave/4.0.3/oct/ 
mips64el-unknown-linux-gnuabi64
/usr/lib/  mipsel-linux-gnu         /octave/4.0.3/oct/ 
mipsel-unknown-linux-gnu
/usr/lib/  powerpc-linux-gnu        /octave/4.0.3/oct/ 
powerpc-unknown-linux-gnu
/usr/lib/  powerpc64-linux-gnu      /octave/4.0.3/oct/ 
powerpc64-unknown-linux-gnu
/usr/lib/  powerpc64le-linux-gnu    /octave/4.0.3/oct/ 
powerpc64le-unknown-linux-gnu
/usr/lib/  s390x-linux-gnu          /octave/4.0.3/oct/  s390x-ibm-linux-gnu
/usr/lib/  sparc64-linux-gnu        /octave/4.0.3/oct/ 
sparc64-unknown-linux-gnu
/usr/lib/  x86_64-kfreebsd-gnu      /octave/4.0.3/oct/ 
x86_64-pc-kfreebsd-gnu
/usr/lib/  x86_64-linux-gnu         /octave/4.0.3/oct/  x86_64-pc-linux-gnu



I think it's safe to remove the VENDOR part of the GNU triplet, in most cases
the path component that we compute from the canonical host identifier will be
the same as the Debian multiarch tuple.

The one quirk is ix86, but I think it's fine to continue using i686 as the CPU
identifier that config.guess normally returns (or is specified by the user).
Debian builds packages with "--build=i686-linux-gnu" and continues to call the
architecture i386, just a quirk everyone is used to.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48710>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/