Reenvasado de software propietario

Estaba pensando en intentar empacar Matlab (una pieza de software patentada) para Arch Linux mediante la creación de un PKGBUILD para manejar la installation, las dependencies y los conflictos. Con el instalador estándar de Matlab Linux, coloca todo en un directory local y no requiere muchos packages externos.

Dicho esto, proporciona una serie de files de biblioteca estándar (por ejemplo, libgcc_s.so y libstdc ++. So), así como un JRE completo. ¿Pueden estos types de files ser eliminados (posiblemente reemplazados por enlaces) y suministrados por dependencies de packages adicionales?

Intento mantener el package de PHP App Engine en AUR y lo estoy instalando en /opt que es donde debe colocar un package de Matlab autónomo (en algo como /opt/matlab ) y volver a vincular sym el ejecutable a /usr/bin y otras cosas a /usr/share/applications y qué no.

Echaré un vistazo a algunos otros packages que vuelven a empaquetar binarys para arch. Al igual que los packages de Dropbox o Google Chrome . El package de Chrome, en particular, depende del binary de Debian, por lo que eliminan los detalles de Debian cuando se instala en arch.

Por otro lado, si sueltas todo en /opt/matlab como está, en lugar de tirar bibliotecas comunes y el JRE, es mucho más probable que tengas un Matlab que funcione que no se rompa o que deba volverse a probar y vuelva a funcionar. -packaged cada vez que cambia una dependencia.

Podría ofrecer dos sabores: un package completo de Matlab y un package mínimo de Matlab.

No veo por qué la eliminación sería un problema y el reemploop con enlaces, suponiendo que sean idénticos a las versiones que se incluyeron con la installation de Matlab. Pero de alguna manera esto parece que estás haciendo mucho trabajo por ti mismo.

Cuando solía apoyar a un grupo donde manteníamos muchas versiones de packages propietarios como Matlab, nuestro grupo los instalaba en directorys independientes y utilizaba una herramienta similar a los modules para mantener la administración del entorno del usuario cuando querían cambiarlo. para que puedan usar estos packages.

Consulte esta sección de preguntas y respuestas de U & L titulada: Agregue múltiples subdirectorys bajo el mismo directory padre a PATH donde analizo varias tácticas para administrar la $PATH entorno $PATH un sistema. Estas mismas tácticas también se pueden aplicar a casi cualquier variable de entorno. A menudo, esto es lo que controla la funcionalidad de las aplicaciones propietarias.

Hay dos razones por las que las aplicaciones grandes vienen con bibliotecas integradas. Una razón es que evita que los usuarios tengan que rastrear todas las bibliotecas, encontrar qué package las contiene en su distribución, asegurarse de que tengan las versiones correctas, etc. Mantener packages binarys que funcionen en todas las distribuciones es complicado porque en un punto determinado a time, las distribuciones a menudo envían diferentes versiones de la biblioteca. Si su package es para un lanzamiento determinado de una distribución dada, entonces confiar en la versión de la distribución no es un problema. Pero con Arch Linux, debido a la falta de versiones estables, tendrá que actualizar su package muy a menudo si no incluye al less las bibliotecas que cambian rápidamente.

La otra razón para agrupar bibliotecas es que a veces los progtwigs tienen dependencies en versiones de bibliotecas específicas. En principio, las bibliotecas tienen numbers de versión de dos partes: un número de versión principal que cambia cada vez que ABI¹ cambia de manera incompatible, y un número de versión menor que cambia cada vez que algo cambia (por ejemplo, una corrección de error o una nueva característica que no romper la compatibilidad con versiones anteriores). (Muchas bibliotecas tienen un número de versión de la forma MAJOR.MINOR pero esto no es universal.) Los files binarys de la biblioteca con diferentes versiones principales tienen diferentes sonames , de modo que se pueden instalar juntos, mientras que los files binarys de la biblioteca que solo difieren por su versión secundaria el mismo soname, de modo que solo se encuentre uno por enlace dynamic. Si el progtwig fue creado y probado para la versión 1.2, pero tiene la versión 1.3, el progtwig debería funcionar. Sin embargo, a veces los progtwigs utilizan interfaces no documentadas que no son parte de la ABI y que pueden estar rotas en 1.3. Como las testings con todas las combinaciones de versiones de biblioteca posibles serían una pesadilla de soporte, los distribuidores de binarys prefieren que todos los usuarios usen las mismas versiones de biblioteca (con una exception para algunas bibliotecas del sistema, especialmente libc).

¹ Application Binary Interface: la especificación de la interfaz entre la biblioteca comstackda y el progtwig comstackdo.