hogar / Consejos/ Cómo instalar el programa descargado en Fedora. Cómo instalar software en Fedora

Cómo instalar el programa descargado en fedora. Cómo instalar software en Fedora

Los sistemas FOSS en general, y Fedora en particular, están empaquetados. Del mismo modo, en forma de paquetes, cualquier programas adicionales para ellos, creado por desarrolladores independientes. Y por lo tanto, una de las tareas importantes del usuario es la integración de paquetes en su sistema. Los paquetes para Fedora se distribuyen en formato rpm.

formato rpm

La invención del formato de paquetes rpm y la correspondiente utilidad para gestionarlos tuvo un impacto muy grande en la distribución de Linux en general. Así que tienes que prestarle un poco de atención.

Historia

El formato de paquete RPM (que entonces significaba Red Hat Package Manager) y la utilidad del mismo nombre para manipular dichos paquetes, capaz de rastrear dependencias e informar su violación, jugaron un papel muy importante en la presentación de Linux al público en general. Es cierto que esta utilidad no sabía cómo resolver dependencias y no ha aprendido hasta el día de hoy: esta tarea se resuelve con herramientas de administración de paquetes más "avanzadas". Pero en comparación con el kit de herramientas de paquete silencioso de Slackware, las dependencias no se rastrearon en absoluto, y esto fue una gran mejora desde el punto de vista de los usuarios habituales.

El origen del sistema RPM (nos referiremos tanto al conjunto de utilidades como al formato de los paquetes con los que trabajan) se pierde en la noche de los tiempos. Las primeras versiones de Red Hat usaban el sistema RPP, que proporcionaba la instalación de paquetes con un solo comando, la consulta de información sobre ellos y la verificación de dependencias. Sin embargo, la creación de paquetes para él requirió una modificación significativa de las fuentes del autor, lo que fue estresante para los mantenedores de la distribución.

Paralelamente a los primeros Red Hat, la distribución Bogus, ahora poco conocida, se desarrolló durante algún tiempo. Tenía su propio sistema de paquetes: PMS (Sistema de gestión de paquetes), escrito por Rikard E. Faith. Tenía un mecanismo débil para solicitar información sobre los paquetes, y la verificación de sus dependencias simplemente no existía. Pero, por otro lado, los paquetes para PMS podrían construirse directamente desde las fuentes del autor, sin ninguna modificación.

Durante la preparación del segundo lanzamiento de Red Hat, Rickard Veit, junto con Doug Hoffman (Doug Hoffman), bajo un contrato con Red Hat, escribieron un sistema PM (Gestión de paquetes) que incorporó las mejores características de RPP y PMS. Aunque prácticamente nunca se usó, sirvió como uno de los cimientos de RPM.

El propio sistema RPM fue creado por Mark Ewing (uno de los cofundadores de la empresa) y Erik Troan, basándose en todos los logros de sus predecesores: los desarrolladores de RPP, PMS y PM. Una versión del mismo, preparada para las versiones de prueba de la segunda versión, se escribió en Perl en aras de la velocidad, lo que creó una serie de problemas, por ejemplo, al arrancar desde un disquete (y en esos días era bastante común). forma de iniciar Linux). Y justo antes del lanzamiento de Red Hat 2.0, el sistema se reescribió completamente en C, la base de datos de paquetes se rediseñó para una mayor confiabilidad y velocidad, y la biblioteca rpmlib se creó para usar la funcionalidad RPM por parte de desarrolladores externos. En otras palabras, el sistema RPM ha adquirido casi la forma en que lo conocemos ahora, y desde entonces solo ha sido objeto de correcciones de errores y mejoras cosméticas.

El sistema RPM (es decir, el formato y la utilidad), al convertirse en estándar y estar disponible públicamente en el lanzamiento de Red Hat 2.0, lanzado en septiembre de 1995, inmediatamente ganó popularidad fuera del sistema principal. Pronto se usaron en Caldera Linux (más tarde llamado OpenLinux), que originalmente era un clon exacto de Red Hat. Después de eso, el kit de distribución Suse (genéticamente descendiente de Slackware) cambió a paquetes en formato rpm. Por supuesto, todos los clones y derivados posteriores de Red Hat, como Mandrake, también usaron RPM.

Puedo testificar como testigo presencial que a finales de 1996-1997 (la época de mis primeros experimentos con Linux), el sistema RPM estaba muy extendido, se consideraba estable y se usaba mucho más allá de la distribución nativa.

información general

Durante su dilatada vida, el formato rpm ha sufrido diversos cambios, pero en su línea general ha conservado tanto sus rasgos característicos como su retrocompatibilidad hasta la actualidad. Su versión actual de entre las soportadas oficialmente por el proyecto del mismo nombre en estos momentos (01/02/2011) es la 4.8.1. Se utiliza en innumerables distribuciones que aparecen como clones directos de Red Hat (CentOS, Scientific Linux, Oracle Linux empresarial), y sus derivados, incluso si se han alejado del progenitor, como Mandriva o Altlinux. Además, se puede ver incluso en algunos sistemas que no están relacionados genéticamente con él (por ejemplo, en todas las variantes de Suse).

Paralelamente a la versión general de rpm, también se está desarrollando una versión actualizada de la misma, conocida como rpm5. Fue creado por Jeff Johnson, quien anteriormente fue uno de los principales desarrolladores de las rpm "regulares". De acuerdo con él, una nueva version mejoró significativamente en comparación con su antecesor, por lo que, sin embargo, tuvo que pagar una falta de compatibilidad entre estos dos formatos. Por lo tanto, rpm5 no es compatible oficialmente ni con el proyecto rpm ni con ninguna de las distribuciones populares basadas en rpm. Se usa, hasta donde yo sé, solo en la distribución PLD y, según el anuncio, se usará en el lanzamiento de Mandriva 2011.1

Si bien las distribuciones basadas en rpm enumeradas (y muchas otras no enumeradas) teóricamente usan el mismo formato de paquete, los detalles reales de su disposición difieren. Esto es especialmente cierto para los paquetes fuente (que se discutirán por separado). Sin embargo, en estas páginas me limitaré a los rpm de la distribución de Fedora. Cierto, lo dicho sobre ellos también será válido para RHEL, CentOS, Scientific Linux, Oracle Enterprise Linux, ASPLinux.

Nomenclatura del paquete

Como parte de la distribución de Fedora, se pueden encontrar distintos tipos de paquetes del formato que nos interese.

Primero, se asignan paquetes rpm binarios y son lo mismo, pero con textos fuente. Como sugiere su nombre, el primero contiene los componentes precompilados del paquete de distribución, tales como:

binarios ejecutables;
tal vez las bibliotecas necesarias para su funcionamiento;
archivos de configuración (o al menos ejemplos de ellos);
documentación.

Los paquetes fuente contienen sus tarballs, los parches necesarios para la adaptación de los paquetes del autor al sistema de destino y varios tipos de información de servicio.

Es muy fácil reconocer ambos por sus nombres formados de acuerdo con ciertas reglas, que consideraremos usando el ejemplo del paquete más indicativo: el paquete rpm en sí.

Los nombres de los paquetes rpm binarios se forman de acuerdo con el siguiente esquema:

Rpm-4.8.1-6.fc14.x86_64.rpm

donde rpm es el nombre del paquete, 4.8.1 es el número de rama, versión y versión específica del paquete, 6 es el número de compilación de la versión actual de esta distribución, fc14 es el nombre y la versión de la misma (que es, en este ejemplo, Fedora versión 14), x86_64: la arquitectura para la que se creó el paquete.

El nombre del paquete fuente será algo como:

RPM-4.7.1-6.fc12.src.rpm

Puede ver que la diferencia está solo en el sufijo src adicional, que simboliza que estamos tratando con un paquete fuente y no con un binario precompilado. Y es obvio que el concepto de arquitectura para los códigos fuente no tiene sentido: (teóricamente) deberían construirse para cualquiera de ellos.

Entre los paquetes binarios, también puede encontrar aquellos que no están vinculados a ninguna arquitectura; se identifican con el sufijo adicional noarch. Entre ellos se encuentran scripts en lenguajes interpretados como Perl, Python, etc., paquetes de fuentes, documentación, etc. Por ejemplo, un paquete para uno de los tipos de letra Dejavu se vería así:

dejavu-sans-fuentes-2.30-2.fc12.noarch.rpm

Ya se ha dicho anteriormente que los paquetes rpm binarios pueden contener bibliotecas de funciones necesarias para su funcionamiento. Sin embargo, esto es más bien una excepción: como en todos Sistemas tipo UNIX, hay una tendencia en las distribuciones basadas en rpm a construir bibliotecas como paquetes separados. En este caso, cada biblioteca, por regla general, se presenta en forma de dos paquetes.

El primer paquete contiene el código real para las funciones de biblioteca necesarias de todos modos; por ejemplo, el paquete rpm lo proporciona un paquete de biblioteca

rpm-libs-4.7.1-6.fc12.x86_64.rpm

El segundo paquete incluye archivos de encabezado, necesario solo para el autoensamblaje de paquetes; en la vida cotidiana puede prescindir de ellos:

rpm-devel-4.7.1-6.fc12.x86_64.rpm

Habiendo tratado la nomenclatura de los paquetes rpm, podemos pasar a la cuestión de su estructura interna, es decir, al formato real.

Organizar paquetes rpm binarios

El paquete binario rpm incluye dos componentes. Por un lado, es un conjunto de archivos compilados, como binarios y bibliotecas ejecutables, acompañados de las configuraciones necesarias, documentación, etc., listos para ser incorporados a la jerarquía de archivos del sistema.

Por otro lado, el paquete contiene metainformación, una descripción compilada de acuerdo con ciertas reglas. Incluye el nombre del paquete, la versión y el número de compilación, información sobre el desarrollador y su sitio maestro, una lista de archivos, su posición en la jerarquía de archivos, una lista de dependencias. Si es necesario, puede haber scripts de instalación y configuración. Todo esto en conjunto le permite controlar la integridad del paquete, realizar un seguimiento de las dependencias, garantizar la ejecución del procedimiento de instalación real y también eliminar los paquetes "directamente".

Los componentes de un paquete rpm se empaquetan en un archivo cpio, una de las herramientas de archivo más antiguas de UNIX, sujeto a compresión. Anteriormente, hasta la versión 11 de Fedora inclusive, esto se hacía usando la utilidad gzip. A partir de la versión 12 de Fedora, los paquetes rpm se comprimen mediante el algoritmo LZMA, que proporciona un grado de compresión mucho mayor, pero a costa del tiempo que se dedica a ello. Lo cual, sin embargo, no causará ningún inconveniente para el usuario, porque el desempaquetado de archivos lzma, paradójicamente, se lleva a cabo casi a la misma velocidad que gzip . Pero descargarlos, por supuesto, es mucho más rápido, lo que no puede dejar de complacer a los propietarios de canales “gruesos” y baratos: en estas condiciones, instalar paquetes a través de la Red es más rápido que desde medios locales.

Volvamos, sin embargo, al hecho de que el paquete rpm tiene "adentro". ¿Por qué desempaquetar primero el paquete con cualquier herramienta estándar(rpm2cpio, por ejemplo, o usando la utilidad rpm2tgz) y vea qué sucede:

$ ls rpm-4.7.1-6/ bin/ etc/ usr/ var/

Es decir, vemos aquellos componentes del paquete que se incorporarán a la jerarquía de archivos del sistema de destino.

La forma más fácil de familiarizarse con el segundo componente es con la ayuda de Midnight Commander. Por clave F3(como antes, el paquete rpm se considera como un ejemplo) proporcionará toda la metainformación en forma de resumen. Primero, esta será una descripción formal del paquete:

Nombre: rpm Reubicaciones: (no reubicable) Versión: 4.8.1 Proveedor: Fedora Versión del proyecto: 5.fc14 Fecha de compilación: martes, 10 de agosto de 2010 11:43:21 Fecha de instalación: (no instalado) Host de compilación: x86-12.phx2 .fedoraproject.org Grupo: Entorno del sistema/Fuente base RPM: rpm-4.8.1-5.fc14.src.rpm Tamaño: 2035701 Licencia: GPLv2+ Firma: RSA/SHA256, miércoles 11 de agosto de 2010 05:58:10, ID de clave 421caddb97a1071f Empaquetador: URL del proyecto Fedora: http://www.rpm.org/ Resumen: El sistema de gestión de paquetes RPM Descripción: El Administrador de paquetes RPM (RPM) es un potente sistema de gestión de paquetes controlado por línea de comandos capaz de instalar, desinstalar, verificar, consultar y actualizar paquetes de software. Cada paquete de software consta de un archivo de archivos junto con información sobre el paquete, como su versión, una descripción, etc.

El significado de todos los campos es intuitivo. Solo preste atención al campo Grupo: tendremos que recordar la propiedad grupal del paquete cuando se trata de administrar paquetes usando el sistema yum.

A continuación, seguirá el script de instalación:

Posttrans scriptlet (usando /bin/sh): # XXX esto es torpe y feo, rpm debería manejar esto dbstat=/usr/lib/rpm/rpmdb_stat if [ -x "$dbstat" ]; entonces si "$dbstat" -e -h /var/lib/rpm 2>&1 | grep -q "no" coincide con la versión del entorno | Argumento inválido"; luego rm -f /var/lib/rpm/__db.* fi fi exit 0

Rwxr-xr-x 1 raíz raíz 20392 10 de agosto 11:42 /bin/rpm drwxr-xr-x 2 raíz raíz 0 10 de agosto 11:42 /etc/rpm -rwxr-xr-x 1 raíz raíz 7424 10 de agosto 11: 42 /usr/bin/rpm2cpio...

Entonces - archivos de biblioteca:

Rw-r--r-- 1 raíz raíz 40537 10 de agosto 11:42 /usr/lib/rpm/macros drwxr-xr-x 2 raíz raíz 0 10 de agosto 11:42 /usr/lib/rpm/platform drwxr-xr -x 2 raíz raíz 0 10 de agosto 11:42 /usr/lib/rpm/platform/amd64-linux ...

Rw-r--r-- 1 raíz raíz 44206 7 de diciembre de 2009 /usr/share/doc/rpm-4.8.1/COPYING -rw-r--r-- 1 raíz raíz 639 7 de diciembre de 2009 /usr/share/ doc/rpm-4.8.1/CREDITS -rw-r--r-- 1 raíz raíz 496233 11 de junio de 2010 /usr/share/doc/rpm-4.8.1/ChangeLog.bz2 -rw-r--r-- 1 raíz raíz 656 7 de diciembre de 2009 /usr/share/doc/rpm-4.8.1/GROUPS ...

Y finalmente, archivos variables:

Drwxr-xr-x 2 raíz raíz 10 de agosto 11:42 /var/lib/rpm -rw-r--r-- 1 raíz raíz 10 de agosto 11:42 /var/lib/rpm/Basenames -rw-r -- r-- 1 raíz raíz 0 10 de agosto 11:42 /var/lib/rpm/Conflictname -rw-r--r-- 1 raíz raíz 0 10 de agosto 11:42 /var/lib/rpm/Dirnames .. .

Toda esta información se puede ver en partes, fijando el cursor en el archivo en Midnight Commander

Rpm-4.7.1-6.fc12.x86_64.rpm

y presionando Ingresar.
Ahora veremos una lista de los archivos de “meta-información” incluidos en el paquete:

/.. │-on-up-│ 16 de diciembre 12:04 /Info │ 0 │ SC 21 00: 00 00 00 │CPIO │ 0 │S 21 00:00 Encabezado │ 1185 │S 21 00:00 *Instalar │ 39 P. 21 00:00 *ACTUALIZAR │ 39│21 sep 00:00

El contenido de los archivos es fácil de adivinar. Entonces, CONTENTS.cpio es una lista completa de todos los archivos y sus rutas:

Rwxr-xr-x 1 raíz raíz 20808 21 de septiembre 17:30 ./bin/rpm drwxr-xr-x 2 raíz raíz 0 21 de septiembre 17:30 ./etc/rpm ...

etcétera. El archivo HEADER contiene la misma descripción que acabamos de ver F3, *INSTALL y *UPGRADE son scripts ejecutables del destino correspondiente. Y en el directorio /INFO hay muchos archivos pequeños, de los cuales finalmente se recopila la metainformación total. De estos, me centraré solo en REQUIRENAME: esta es la notoria lista de dependencias, que para el paquete rpm se parece a esto:

/bin/bash /bin/sh /bin/sh config(rpm) = 4.8.1-5.fc14 coreutils curl db4-utils libacl.so.1()(64 bits) ...

De hecho, el paquete rpm no contiene ninguna jerarquía de archivos en su interior. Y lo que nos aparece como tal es enteramente mérito de Midnight Commander, que lo restaura en la forma en que estaba antes del montaje.

Base de datos RPM

La base de datos de paquetes rpm es un componente necesario para el funcionamiento del sistema: es ella la que proporciona la capacidad de obtener información sobre los paquetes, actualizarlos y eliminarlos. Se crea durante la instalación del sistema en el directorio /var/lib/rpm y cambia con cada operación con paquetes.

La base de datos del paquete rpm utiliza Berkeley DB, un DBMS antiguo (embotellado en 1986), simple (no relacional), pero rápido, eficiente y, por lo tanto, ampliamente utilizado hasta el día de hoy.

Los archivos base RPM son binarios, e incluso la magia del "comandante nocturno" no te permitirá ver nada inteligible en ellos. Así que solo queda tomar la palabra de los autores de la documentación que

el archivo de paquetes es el principal y almacena los campos de encabezado de paquete indexados,
Los archivos Basenames, Group, Requireversion y otros se utilizan para optimizar las consultas de la base de datos, y
archivos __db.001, __db.002, etc.: contienen información sobre qué archivos se modificaron y crearon al instalar y eliminar paquetes.

La base de datos del paquete rpm es necesaria para funcionamiento normal de este sistema: su daño conlleva consecuencias desagradables y, por lo tanto, hay formas de restaurar su integridad en situaciones de emergencia, que consideraremos a su debido tiempo.

utilidad rpm

Habiéndonos familiarizado con la estructura de los paquetes rpm en términos generales, veamos qué se puede hacer con ellos. Y comencemos con la utilidad del mismo nombre, diseñada para trabajar con paquetes individuales. En los viejos tiempos, era una bendición y una maldición para los usuarios novatos de la distribución Red Hat, sus clones y derivados.

Introducción

Como ya se mencionó, la utilidad rpm ha sido una bendición para los usuarios de la distribución Red Hat y todos sus sucesores. Pues los liberó de la necesidad de autocompilarse: casi todos los desarrolladores, entre los que no desdeñaban distribuir sus paquetes en formato binario, los compilaban en formato rpm, y servicios como http://rpmfind.net facilitaban su localización. En la red. Recuerdo que en aquellos años circulaba tal máxima de vida:

con la ayuda de rpm e Internet, cualquier kit de distribución se puede hacer hermanos gemelos de la noche a la mañana

Sin embargo, también resultó ser la maldición de los usuarios, especialmente de los principiantes: mientras rastreaba las dependencias de los paquetes durante la instalación y eliminación, la utilidad rpm no las resolvía en absoluto, sino que solo informaba sobre la sedición detectada, y en una forma que era bastante incomprensible para Un principiante.

Esos días han pasado: la era de los repositorios empaquetados y las herramientas para trabajar con ellos, como apt-rpm, urpmi y, finalmente, yum, es el personaje principal de la próxima serie de notas. Cuáles se encargan de la manipulación rutinaria de paquetes. Sin embargo, la utilidad rpm sigue siendo la herramienta más fácil para manejar paquetes individuales, especialmente aquellos que no están incluidos en los repositorios oficiales. Y en algunos casos, por ejemplo, al conectar repositorios de terceros, puede ser casi indispensable.

Así que tomemos un tiempo para familiarizarnos con su básico, más popular en La vida cotidiana, funciones. Esto es solo un resumen para uso práctico. Además, está dirigido a aquellos que no han tratado previamente con sistemas basados en rpm. Los que gritarán desde la audiencia - denme los detalles, se los envío con anticipación a la tía Mana, ella les contará todo.

características generales

La utilidad rpm, al igual que dpkg en las distribuciones basadas en Deb, es solo uno de los representantes de toda una familia desarrollada, junto con el formato del mismo nombre, como parte de un proyecto independiente.

Entre las utilidades adicionales, vale la pena mencionar rpm-build, una herramienta para crear sus propios paquetes, y rpm2html, una utilidad para extraer metainformación de los paquetes y presentarla en forma humana (se puede encontrar una lista completa de toda la familia ). Sin embargo, al comienzo de esta serie de páginas, solo hablaremos sobre las rpm en sí.

Hay cinco modos principales de usar la utilidad rpm:

modo de consulta (query);
modo de verificación (verificar);
modo de instalación (instalar);
modo de actualización (upgrage);
modo borrar (borrar).

También hay un modo de creación de paquetes, pero no hablaremos de eso por ahora.

Cada modo corresponde a una de las opciones básicas del comando rpm. Pueden ir acompañadas de opciones adicionales, ya sean específicas o comunes a todos los modos. El primero será considerado en la descripción de los modos. Entre los segundos, los siguientes son los más demandados:

-? , --help muestra ayuda detallada sobre el uso del comando rpm (se muestra una breve ayuda en respuesta al comando sin opciones ni argumentos);
--version imprime el número de versión del paquete rpm;
--quiet muestra un mínimo de mensajes durante la ejecución del comando (generalmente solo mensajes de error);
-v imprime mensajes detallados sobre el progreso del comando.

También hay varias opciones "fuera de modo", que se utilizan en particular para restaurar la base de datos del paquete.

El argumento del comando rpm suele ser el nombre del archivo del paquete; a menudo puede haber varios argumentos de este tipo (en el límite, tantos como desee). En algunos casos, basta con especificar un nombre de paquete corto; por ejemplo, para nuestro ejemplo constante solo rpm. En otras situaciones, se requiere el nombre completo, indicando el número de versión, compilación, distribución, arquitectura, por ejemplo, rpm-4.8.1-5.fc14.x86_64.rpm. Y si el archivo del paquete no está en el directorio actual, deberá anteponerle la ruta completa, digamos /var/cache/akmods/ .

Modo de solicitud...

... sirve para obtener información sobre el paquete, en particular, su estado (si está instalado en el sistema). La opción de consulta principal es -q (o --query), en respuesta a ella, se mostrará el nombre completo del paquete:

Rpm -q rpm rpm-4.8.1-5.fc14.x86_64

Llamo su atención sobre el hecho de que un nombre de paquete corto es suficiente como argumento con la opción de solicitud, y el comando en sí se puede dar en nombre de usuario regular.

Las opciones adicionales dependen del propósito de la solicitud. Entonces, la presencia de un paquete en el sistema se verifica con el siguiente comando:

$ rpm -qa nombrepaquete

donde la opción adicional -a (o --all) dirige la consulta a todos los paquetes disponibles en la base de datos. Si el paquete está instalado, la respuesta a este comando será

$ rpm -qa opera opera-10.00-4440.gcc4.shared.qt3.x86_64

De lo contrario, se devolverá el indicador de la línea de comandos.

Se puede obtener una descripción formal del paquete con el comando

$rpm -qirpm

cuya respuesta seria:

Nombre: rpm Reubicaciones: (no reubicable) Versión: 4.8.1 Proveedor: Fedora Versión del proyecto: 5.fc14 Fecha de compilación: martes 10 de agosto de 2010 11:43:21 Fecha de instalación: domingo 31 de octubre de 2010 10:28:06 Host de compilación: x86-12.phx2.fedoraproject.org Grupo: Entorno del sistema/Fuente base RPM: rpm-4.8.1-5.fc14.src.rpm Tamaño: 2035701 Licencia: GPLv2+ Firma: RSA/SHA256, miércoles 11 de agosto de 2010 05:58 :10, ID de clave 421caddb97a1071f Empaquetador: URL del proyecto Fedora: http://www.rpm.org/ Resumen: El sistema de gestión de paquetes RPM Descripción: El Administrador de paquetes RPM (RPM) es un potente sistema de gestión de paquetes controlado por línea de comandos capaz de instalar , desinstalar, verificar, consultar y actualizar paquetes de software. Cada paquete de software consta de un archivo de archivos junto con información sobre el paquete, como su versión, una descripción, etc.

Es fácil ver que este es el mismo ENCABEZADO que vimos anteriormente a través de Midnight Commander.

Una opción l adicional nos permitirá extraer el contenido de CONTENTS.cpio también:

$ rpm -ql rpm /bin/rpm /etc/rpm /usr/bin/rpm2cpio /usr/bin/rpmdb /usr/bin/rpmquery /usr/bin/rpmsign /usr/bin/rpmverify ...

Arriba, hablamos sobre obtener información sobre el paquete instalado. Sin embargo, es mucho más interesante obtener información sobre un paquete que no está instalado, sobre si es necesario o no en nuestro negocio. Y esto es posible: agregando una opción p adicional a -qi y especificando el nombre completo del paquete y la ruta. Y dado que lo más probable es que el paquete desinstalado se encuentre en alguna fuente de red, la URL aparecerá aquí como la ruta, por ejemplo:

$ rpm -qip http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/joe-3.7-5.fc13.x86_64.rpm

Lo que generará exactamente la misma información que cuando se consulta el paquete local:

Nombre: joe Reubicaciones: (no reubicable) Versión: 3.7 Proveedor: Versión del proyecto Fedora: 5.fc13 Fecha de compilación: Mié, 10 de febrero de 2010 09:57:06 Fecha de instalación: (no instalado) Host de compilación: x86-03.phx2.fedoraproject .org Grupo: Aplicaciones/Editores Fuente RPM: joe-3.7-5.fc13.src.rpm Tamaño: 1177186 Licencia: GPLv2+ Firma: RSA/SHA256, miércoles 28 de julio de 2010 21:59:42, ID de clave 421caddb97a1071f Empaquetador: Proyecto Fedora URL: http://sourceforge.net/projects/joe-editor/ Resumen: un editor de texto no modal y fácil de usar Descripción: Joe es un editor de texto no modal, potente y fácil de usar. Utiliza las mismas combinaciones de teclas de WordStar utilizadas en el entorno de desarrollo de Borland.

La opción adicional f le permite especificar el nombre del paquete al que pertenece un determinado archivo:

$ rpm -qf /usr/lib/rpm/rpm2cpio.sh rpm-4.8.1-5.fc14.x86_64

Son posibles muchas más opciones en el modo de consulta, que se pueden encontrar en la página del manual del paquete rpm si es necesario.

Comprobar modo...

...proporciona verificaciones de integridad para el paquete instalado. Esto se hace comparando sus archivos con sus contrapartes del paquete original en términos de parámetros tales como tipo, tamaño, suma de verificación (MD5), propiedad y atributos de acceso. La opción principal para este modo es -V ; sin opciones adicionales, con el nombre del paquete especificado, verifica la ubicación correcta de sus archivos en la jerarquía de archivos.

Si la verificación es exitosa, es decir, los archivos instalados y originales coinciden completamente, no se muestran mensajes, solo se devuelve un mensaje de línea de comando. Si se encuentran discrepancias entre ellos en cualquier parámetro, se mostrará en forma simbólica. Los desajustes se marcan así:

5 - suma de comprobación MD5
talla S
L - enlace simbólico
T - fecha de modificación del archivo
D-dispositivo
U - usuario
grupo G
M - modo (incluyendo permisos y tipo de archivo)
? - no se pudo leer el archivo

Los parámetros coincidentes se indican con un solo punto. Por desgracia, no puedo dar ejemplos: en qué paquete no toco para verificar, todo está en orden. Y no quiero estropearlo a propósito.

Y además, la salida de un mensaje no siempre significa que algo anda mal con el paquete instalado. Por ejemplo, si tratamos de verificar nuestro paquete rpm modal con el comando

$ rpm -V rpm

veremos lo siguiente en la salida:

Preenlace: /bin/rpm: al menos una de las dependencias del archivo ha cambiado desde que se previnculó S.?...... /bin/rpm preenlace: /usr/bin/rpm2cpio: al menos una de las dependencias del archivo ha cambiado cambiado desde previncular S.?...... /usr/bin/rpm2cpio

Esto simplemente significa que los archivos ejecutables del paquete rpm se vincularon previamente después de su instalación (enlace previo: lo que es, se lo diré con el tiempo). Como resultado, por supuesto, perdieron su identidad con sus homónimos del paquete original.

Las opciones adicionales del modo de verificación le permiten verificar un archivo específico:

$ rpm -Vf /usr/bin/rpm2cpio

compare el paquete instalado con su paquete rpm original:

$ rpm -Vp ruta2/nombre_paquete_completo

y también realice una verificación completa de todos los paquetes instalados:

#rpm -Va

Dado que la salida del último comando será muy larga, se recomienda utilizarlo en la raíz con un comando como menos o más. También puede usar grep para encontrar solo paquetes; que contenga discrepancias con el original en uno de los criterios enumerados anteriormente. Por ejemplo, la estructura de mando

#rpm -Va | grep S

le dará a la salida una lista de paquetes que difieren de los originales en tamaño y la canalización

#rpm -Va | grupo 5

detecta diferencias en las sumas de comprobación.

Llamo su atención sobre el cambio en la apariencia de la línea de comando cuando se usa la opción adicional a: si los comandos de verificación anteriores generalmente se ejecutan en nombre de un usuario común, entonces es mejor realizar una verificación completa de todos los paquetes con el administrador derechos, ya que sólo él tiene derecho a acceder a algunos archivos y directorios del sistema.

Además de las enumeradas, hay muchas más opciones para verificar una firma digital y claves públicas; como de costumbre, se pueden encontrar en la página man (8) rpm.

Modos de instalación y actualización...

… están estrechamente relacionados. Sus principales opciones son:

-i (de install, que no debe confundirse con la opción de modo de consulta opcional) instala un paquete que no está presente en el sistema;
-F actualizar el paquete instalado a una versión más "nueva";
-U opción genérica de instalación y actualización: su uso actualizará un paquete instalado e instalará un paquete desinstalado.

Es importante que los alcances de las opciones -i y -F estén estrictamente delimitados: el comando con la primera se negará a ejecutarse si el sistema tiene una versión antigua del paquete del mismo nombre. Y viceversa: el comando con la segunda opción dará un mensaje de error si la versión anterior no está instalada en el sistema. Por lo tanto, la opción genérica -U es la más utilizada. Obviamente, para ejecutar comandos con éxito con cualquiera de estas opciones, se requieren privilegios de administrador.

Los argumentos de los comandos de instalación y actualización deben ser los nombres completos de los archivos del paquete, con la ruta local a ellos, o dirección de red. Argumentos, es decir, paquetes a instalar o actualizar, en el caso general, puede especificar tantos como desee. Y en algunos casos, especificar dos argumentos en un comando es una necesidad.

Mencioné anteriormente que la utilidad rpm no solo instala paquetes, sino que también verifica sus dependencias. Aunque, desafortunadamente, no los permite, solo informa violaciones. Por ejemplo, un intento frontal de instalar kdebase

RPM-ihv

producirá una larga lista de dependencias no satisfechas:

Recuperando http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/kdebase-4.5.2-2.fc14.x86_64.rpm error: Dependencias fallidas: kdebase-libs(x86 -64) = 6:4.5.2-2.fc14 es necesario para kdebase-6:4.5.2-2.fc14.x86_64

Esto, como dicen, es una cuestión de vida, y está claro cómo resolver tal situación. Porque instalar paquetes tan grandes con dependencias tan complejas directamente a través de rpm es una tarea ingrata, se han inventado otras herramientas para eso. Por ejemplo, yum , al que llegaremos en su momento.

Hay situaciones que son más diferentes: un paquete aparentemente simple, al intentar instalarlo, requiere otro como dependencia. Y eso, a su vez, se niega a establecerse, pues se refiere a la ausencia del primero. Entonces, justo ahora, cuando comencé a actualizar uno de mis sistemas experimentales a la versión de cuero crudo, me encontré con el hecho de que el paquete fedora-release-rawhide-15-0.3.noarch.rpm no quería instalarse sin fedora-release -15-0.3.noarch.rpm - y viceversa.

Es en tales casos que se requiere especificar todos los paquetes interdependientes como argumentos para un comando:

# rpm -ivh http://URL/ruta2/(fedora-release-15-0.3.noarch.rpm, fedora-release-rawhide-15-0.3.noarch.rpm)

Y, lo que es típico, el orden de los nombres no toca ningún piano: si se especifican todos los paquetes interdependientes, todos se instalarán correctamente.

En el último comando, aparecieron dos opciones inesperadamente y sin previo aviso: v y h. Sin embargo, el primero ya se mencionó anteriormente: esta opción adicional de todos los modos prescribe mostrar mensajes detallados sobre el progreso de cualquier tarea. Y la opción -h (o --hash) proporciona una forma conveniente de representar esta salida.

Las principales opciones de instalación y actualización se basan en muchas más opciones adicionales, pero detrás de ellas, como siempre, a la tía Mana.

Modo de borrado...

… suele ser tan popular como los modos de instalación y actualización. Sin embargo, la tarea no es difícil, y en el caso general se realiza de la siguiente manera:

# rpm -e nombrepaquete

El nombre del paquete base es suficiente aquí, pero obviamente se requieren derechos de superusuario.

Si las dependencias se rompen durante la desinstalación, se muestra un mensaje de error:

Error: dependencias fallidas:

Por supuesto, se puede ignorar con la opción opcional --nodeps. O bien, si está completamente seguro de que tiene razón, ponga en la línea los comandos de borrado y los nombres de los archivos de los pactos asociados a las dependencias del borrado.

Sin embargo, todo esto está plagado de consecuencias, por lo que en casos ambiguos es mejor no recurrir al comando rpm para eliminar archivos. Por otro lado, como ya se mencionó, yum existe para que el usuario no tiemble.

Repositorios

La utilidad rpm está diseñada principalmente para instalar paquetes individuales desde cualquier fuente: local o de red (por ejemplo, desde sitios de desarrolladores), pero principalmente desde la primera. El sistema de gestión de paquetes yum, por su parte, está enfocado a acceder a repositorios de paquetes, y principalmente a los de red. Aunque tampoco está prohibido su uso con repositorios locales.

que es un repositorio

En primer lugar, intentemos responder a la pregunta de qué es un repositorio. Porque su presencia hoy en día es uno de los principales signos que definen la distribución.

Traducido al ruso, la palabra repositorio medio almacenamiento- y se recomienda su uso por los puristas del lenguaje (son los que prefieren llamarse gramatica nazi). Sin embargo, como suele ser el caso en la vida, se ha establecido un nombre diferente para ellos entre la gente: repos o, hablando en nuestro idioma, en cirílico brasileño, nabos. ¿Por qué en plural? Quedará claro a partir de la historia adicional. Bueno, como sinónimo, prefiero el término infierno.

El repositorio en sí puede definirse realmente como una primera aproximación como un lugar para almacenar paquetes especialmente construidos para una distribución determinada, a los que es posible el acceso libre (estamos hablando sólo de sistemas libres).

Sin embargo, la disponibilidad del servidor que almacena los paquetes no es suficiente para llamarlo repositorio. Los paquetes en un repositorio deben estar estructurados de acuerdo con ciertos principios específicos de distribución. El sistema de almacenamiento debe garantizar su reposición, actualización y, lo que es más importante, soporte para la integridad y consistencia de los paquetes con respecto a las dependencias, y para todas las versiones de distribución compatibles actualmente.

En otras palabras, los paquetes en el repositorio deben ir acompañados de bases de datos, las mismas que utiliza el sistema de gestión de paquetes de la distribución, así como su sistema de empaquetado.

Además, es muy deseable que el repositorio se refleje en varios servidores independientes, por razones obvias. Es cierto que este no es un requisito indispensable. Sin embargo, la presencia de espejos es una de las razones para usar la palabra depósito en plural.

Ahora veamos cómo se ven todas estas consideraciones generales en la práctica, en relación con los repositorios de Fedora.

La estructura física de los repositorios.

Físicamente, los repositorios de Fedora son un conjunto de subdirectorios anidados en servidores ftp o http, y en ocasiones tienen una estructura bastante compleja y no completamente transparente. No es necesario que el usuario lo sepa, pero en una serie de situaciones de emergencia no será superfluo. Y dado que esta estructura no se describe en ninguna parte, al menos en ruso, le prestaremos un poco de atención.

Sin embargo, los lectores impacientes pueden pasar directamente a la siguiente sección sobre la estructura lógica de los repositorios. Y a la forma presente sólo cuando sea necesario.

Estructura del repositorio principal

El jefe, por así decirlo, de almacenamiento de paquetes, como se puede suponer, se encuentra en la dirección y más hacia el interior. Sin embargo, en la práctica, el usuario casi nunca llega: como veremos en el apartado de gestión de paquetes, este sistema lo envía automáticamente…

no, no donde pensabas en la medida de tu depravación, sino en el espejo más veloz. Además, es el más rápido físicamente y precisamente en este momento, porque no se verifica mediante la afiliación zonal y otros signos formales, sino mediante la respuesta a una solicitud real. A menos, por supuesto, que esté instalado el complemento apropiado para yum, pero hablaremos de esto un poco más adelante.

Entonces, al escribir algo como http://download.fedoraproejct.org en la línea del navegador, nuestro usuario soviético terminará en un servidor con una URL como http://mirror.rec.ru/fedora/linux/ (o tal vez incluso y no ru en absoluto). El nombre de este mismo nombre del río no lo pronunciaré; se puede ver una lista completa de posibles opciones aquí http://mirrors.fedoraproject.org/publiclist. Y dar preferencia a uno de ellos significa, como diría Shurik, mostrar injusticia al otro. nombre del río.

Naturalmente, la estructura de todos el nombre de los rios es idéntico, por lo que puede ser considerado en el ejemplo de cualquier espejo.

Entonces, una vez en recname/fedora/linux/, vemos los siguientes directorios:

Como puede suponer, el directorio de desarrollo contiene paquetes que están en estado de desarrollo (el subdirectorio /desarrollo/rawhide/ es importante aquí, al que volveremos en su momento), y los actualizados recientemente se colocan en el directorio de actualizaciones. . Pero el directorio de lanzamientos es exactamente lo que nos interesa actualmente.

12 13 14

y un subdirectorio de prueba. A veces está vacío, el contenido aparece cuando la versión alfa de la próxima versión se separa de la rama desarrollada (el mismo cuero sin curtir).

Sigamos subiendo por el árbol jerárquico. En su rama de lanzamiento, vemos los siguientes subdirectorios:

Todo Fedora en vivo

El primero incluye paquetes varias versiones y compilaciones producidas durante la vigencia de la versión. El primero, como sugiere el nombre, contiene actualizaciones de compilación del paquete actual, mientras que el segundo contiene imágenes de LiveCD para ambas arquitecturas compatibles (i686 y x86_64). Y de eso, y de otro se hablará oportunamente. Pero seguiremos subiendo por el directorio de Fedora, especialmente porque puede considerarse como un ejemplo de la organización de cualquier directorio en los servidores del proyecto.

Entonces, en el directorio fedora/linux/releases/14/Fedora/, puede ver los siguientes subdirectorios:

I386 fuente x86_64

El segundo incluye paquetes fuente rpm (los llamados *.src.rpm), que también se analizarán por separado. El primero y el tercero contienen ensamblajes para arquitecturas de 32 y 64 bits, respectivamente. Obviamente, por dentro son absolutamente iguales, por lo que consideraremos su interior usando el ejemplo de la arquitectura x86_64 más actual.

Sistema operativo iso jigdo

El primero contiene imágenes de discos de instalación: DVD, juego de CD y disco para instalación en red (netinst), que se analizarán en la sección sobre instalación del sistema. El segundo contiene archivos de metadatos para jigdo (Jigsaw Download), un sistema de distribución de archivos de gran tamaño (en este caso, imágenes de los mismos discos de instalación) y cumple el mismo propósito que el anterior. Bueno, en el tercero, en el subdirectorio Paquetes, de hecho, se encuentran los paquetes requeridos.

Además, en el directorio fedora/linux/releases/14/Fedora/x86_64/os/, puede ver archivos de servicio, como claves GPG para autenticación, archivos de descripción del repositorio (en los subdirectorios repodata y repoview), archivos para construir su propios discos de arranque de imágenes (en los subdirectorios de imágenes e isolinux), que actualmente no son de nuestro interés.

En cuanto al contenido del directorio Paquetes, está representado por paquetes rpm, aquellos que son compatibles directamente con el proyecto Fedora.

Estructura del repositorio de RPMFusion

El repositorio principal, sin embargo, no agota la lista de paquetes disponibles para nuestra distribución. También hay un depósito para paquetes adicionales mantenidos por voluntarios como parte de un proyecto independiente: RPMFusion.

El repositorio real de paquetes adicionales se encuentra en . En él vemos dos directorios: libre y no libre. El primero está destinado a software incondicionalmente libre (en el repositorio principal de Fedora, por cierto, solo existen), el segundo es para software, cuya distribución está sujeta a algunas restricciones. Qué exactamente: volveremos a este tema.

La estructura interna de ambos directorios es la misma. Tienen subdirectorios el y fedora. El primero incluye paquetes respaldados desde RHEL y no nos interesa ahora. El segundo incluye subdirectorios:

Desarrollo/lanzamientos/actualizaciones/

así como archivos de descripción del repositorio.

El propósito de los directorios está más o menos claro a partir de sus nombres (volveremos a este tema), por lo que nos centraremos solo en el directorio de lanzamientos. Tiene subdirectorios para media docena de las últimas versiones, incluidas muchas más "profundas" que las que se mantienen en el repositorio principal. En cada uno de ellos veremos un único subdirectorio Todo. Y en él, los subdirectorios "arquitectónicos" ya familiares:

depuración/OS/

En el primero, como puedes suponer, hay información de depuración que ahora no nos interesa. Pero en el segundo - los paquetes reales. Incluido el paquete de descripción del repositorio principal: rpmfusion-free-release. Aquel cuya instalación conduce inequívocamente a la conexión de este "nabo". Y en el subdirectorio correspondiente del directorio nonfree, un paquete similar se nombrará en consecuencia: rpmfusion-nonfree-release.

Estructura del repositorio de RFRemix

A los usuarios del Fedora original en forma pura los repositorios enumerados son suficientes. Sin embargo, para nuestros conciudadanos de habla rusa, si no es obligatorio, es más que deseable familiarizarse con el repositorio russianfedora.

Se encuentra en el directorio del mismo nombre en la siguiente dirección (que yo sepa, la única hasta el momento). Y su estructura es la siguiente: en el primer nivel de anidamiento hay subdirectorios

build/ con archivos de descripción del repositorio,
releases/ con imágenes de discos de instalación y LiveCD, y
russianfedora/ que contiene los paquetes reales.

Por el momento solo nos interesa el último subdirectorio. Incluye tres subdirectorios:

fixes/ , que representa una especie de delta entre los paquetes básicos y adicionales del Fedora original, por un lado, y RFRemix, por el otro;
free/ , destinado a paquetes completamente gratuitos del proyecto ruso Fedora;
nonfree/ , destinado a paquetes del proyecto ruso Fedora, cuya distribución está restringida por las leyes de algunos países (pero no la nuestra).

La composición de las tres categorías se analizará con más detalle en la siguiente sección; por ahora, solo nos interesa la estructura física de los directorios correspondientes.

Es idéntico: cada uno de ellos incluye los subdirectorios el/ y fedora/ del mismo propósito que en RPM Fusion. El subdirectorio fedora/, a su vez, tiene subdirectorios de desarrollo/, versiones/ y actualizaciones/, y el subdirectorio de versiones/ contiene directorios para los números de versión principales, actualmente del 10 al 15.

Dentro de cada directorio de versión, vemos un único subdirectorio, Everything/ , que incluye subdirectorios para ambas arquitecturas admitidas, i386/ y x86_64/ , y un subdirectorio source/ para los paquetes fuente. Y finalmente, un piso más abajo están los subdirectorios debug/ y os/ de propósito claro (es decir, lo mismo que en RPM Fusion).

Repositorios adicionales

Los repositorios descritos anteriormente serán suficientes para la mayoría de los usuarios en casi todas las ocasiones. Sin embargo, en algunos casos es necesario paquetes adicionales, en los "nabos" oficiales por una u otra razón no incluidos, quizás aún no incluidos. Un ejemplo típico hoy en día es el navegador Chromium: no se encuentra ni en RPM Fusion ni en Russian Fedora.

Y aquí el repositorio Fedora People vendrá al rescate en primer lugar: está diseñado específicamente para paquetes compilados por mantenedores independientes. En términos de contenido, no se superpone con los repositorios oficiales y "semioficiales", sin embargo, hasta donde yo sé, sus paquetes están probados para compatibilidad con ellos y, por lo tanto, se pueden usar sin temor.

La estructura del repositorio de personas de Fedora es extremadamente simple: en la dirección especificada, verá muchos directorios cuyos nombres repiten los nombres de los paquetes que contienen. Dentro de cualquiera de estos, habrá una serie de subdirectorios para el rango de versiones admitidas, diferentes en diferentes casos. Y el subdirectorio de cada versión contiene tres subdirectorios estándar: i386/, SRPMS/ y x86_64/, que contienen el archivo de descripción del repositorio y los archivos del paquete real.

En algunos casos, el repositorio ATrpms puede ser de interés. Contiene numerosos paquetes de contenido multimedia, compilaciones de kernel especializadas, abundantes controladores para tarjetas de video Nvidia (incluidos modelos más antiguos que ya no se encuentran en el sitio web oficial de la empresa). CON lista completa se pueden ver los paquetes y ver la lista de versiones admitidas.

En artículos y reseñas dedicados a Fedora, puede encontrar referencias a muchos otros repositorios adicionales para esta distribución; su lista se puede ver, por ejemplo, en enlaces de los mismos ATrpms. Sin embargo, casi todos ellos han perdido relevancia. Algunos (Livna, Freshrpms, Dribble) ahora se fusionan en RPM Fusion. Otros contienen paquetes para versiones muy antiguas de Fedora. Bueno, el repositorio de Tigro se convirtió en la base de Russian Fedora, aunque será útil para los propietarios perezosos de versiones antiguas de Fedora por sí solo.

Organización lógica de los repositorios

La estructura física de los repositorios de Fedora, especialmente el principal, parece bastante confusa. Afortunadamente, el usuario, como ya se mencionó, prácticamente no tiene que lidiar con eso. En 99 casos, hay 100 de ellos, es suficiente para él navegar en su organización lógica, que ahora consideraremos.

Clasificación del programa

Para empezar, conviene decir por qué antes se usaba la palabra repositorios en plural. Y para ello es necesario considerar la clasificación de paquetes adoptada en esta distribución. Es extremadamente simple e incluye solo dos categorías.

La segunda categoría se llama no libre: el nombre no tiene mucho éxito, porque evoca asociaciones con todo tipo de warez, falsificaciones o la necesidad de realizar pagos al usarlos. De hecho, esto no es absolutamente cierto. La categoría no libre combina exclusivamente libre (en el sentido cerveza gratis) y programas distribuidos legalmente. Sin embargo, existen ciertas restricciones en su distribución. Y por lo tanto, desde el punto de vista de la FSF, no pueden llamarse verdaderamente libres (en el sentido palabra libre).

Por un lado, los programas que se distribuyen solo en forma binaria entran en la categoría no libre, sin restricciones, pero también sin código fuente. Ejemplos de tales programas son controladores propietarios dispositivos tales como tarjetas de video y dispositivos de red, o Flash Movie Player de Adobe, Navegador Ópera, algunas fuentes y juegos.

Por otro lado, el concepto nonfree incluye programas que están disponibles en código fuente y, al parecer, son completamente gratuitos. Sin embargo, su distribución en algunos estados está limitada por razones legales. Un ejemplo típico de esto son los códecs multimedia basados en algoritmos que han sido patentados en un país que reconoce las patentes de algoritmos. En la mayoría de los demás países, que no han pensado en esto, su distribución es absolutamente legal.

Bueno, las categorías libre y no libre son repositorios lógicamente independientes, y esta es la primera razón por la que este término suele aparecer en plural. Y aprenderemos sobre otras razones en la página siguiente.

Repositorios principales

Primero, veamos los repositorios principales que se conectan automáticamente al instalar RFRemix.

El principal repositorio de proyectos de Fedora, mantenido oficialmente, contiene solo paquetes en la categoría gratuita. Y es por eso que se llama simple y sin pretensiones: fedora , descifrado como número de versión y arquitectura de destino, por ejemplo: Fedora 15 - x86_64.

Pero RPMFusion incluye paquetes completamente gratuitos y "no gratuitos". Es por eso que separa dos repositorios: rpmfusion-free y rpmfusion-nonfree.

Organización interna Russian Fedora es aún "más rico": tiene hasta tres repositorios:

russianfedora-fixes: estos son paquetes que están disponibles en los repositorios de fedora o rpmfusion, pero presentados con versiones más nuevas o adaptadas a nuestras condiciones y al entorno cirílico; los paquetes de este repositorio no están separados en libres y no libres;
russianfedora-free: paquetes completamente gratuitos, que no se encuentran en los repositorios de fedora o rpmfusion;
russianfedora-nonfree - "no del todo libres", en el sentido indicado en la última página, paquetes que tampoco están en los repositorios originales de Fedora.

Esta es la rama maestra de los repositorios para cada versión. Se acompaña de varios adicionales que están llenos de paquetes actualizados entre lanzamientos:

actualizaciones - para el propio Fedora;
rpmfusion-free-updates - para Rpmfusion-free;
rpmfusion-nonfree-updates - para rpmfusion-nonfree;
russianfedora-fixes-updates - para Ruso Fedora Fixes;
russianfedora-free-updates - para Russian Fedora Free;
russianfedora-nonfree-updates - para Russian Fedora Nonfree.

Además, cada uno de los repositorios principales corresponde a ramas especiales de paquetes depurados y probados: fedora-debuginfo y fedora-updates-testing, respectivamente - para el repositorio principal y formado a imagen y semejanza - para todos los demás.

Y finalmente, está la rama de depósitos de cuero crudo. Contiene paquetes para la próxima versión de la distribución actualmente en desarrollo y, naturalmente, incluye los mismos repositorios que las ramas de versión estable: fedora-rawhide, rpmfusion-free-rawhide, rpmfusion-nonfree-rawhide, etc.

Lo anterior se refería a los repositorios de paquetes binarios para las arquitecturas i386 y x86_64. Sin embargo, también hay repositorios de fuentes: fedora-source, rpmfusion-free-source, etc.

La solución de aplicación "1C: Retail 8" automatiza el registro de las siguientes operaciones:

llegada de mercancías de la contraparte a los almacenes de la tienda;
venta de bienes y servicios a una contraparte;
movimiento de mercancías entre tiendas, almacenes internos de tiendas, tiendas y almacenes de una empresa comercial;
el comercio de conjuntos de bienes creados tanto en el momento de la venta de los bienes como con la preparación previa a la venta del conjunto;
devoluciones de bienes de compradores, incluidas las devoluciones después del cierre de la caja registradora;
inventario de existencias de productos básicos;
registro de pedidos de efectivo entrantes y salientes directamente en las tiendas;
registro de recibos de venta, y al final del cambio del informe consolidado en la caja registradora, teniendo en cuenta los bienes devueltos al turno;
Moviente Dinero entre tiendas, cajas internas de tiendas, tiendas y cajas de una empresa comercial;
trabajar con sistemas de adquisición, contabilidad de pagos de bienes mediante tarjetas de pago, contabilidad de acuerdos de adquisición y condiciones para la devolución / no devolución de la concesión comercial por parte del adquirente al devolver bienes; trabajar con prestamos bancarios.
el uso de descuentos porcentuales en tarjetas de descuento (descuentos fijos y acumulativos), descuentos con división por tiendas, descuentos por contraparte, descuentos en el monto del cheque, descuentos por período de vigencia, por cantidad de bienes, por tipo de pago.
soporte de equipo comercial: registradores fiscales, terminales de recogida de datos, lectores de códigos de barras, balance electrónico, pantallas de clientes, sistemas de adquisición, lectores de tarjetas magnéticas.

La solución de aplicación "1C: Retail 8" puede trabajar con bases de información distribuidas geográficamente (RIB). Al mismo tiempo, se asegura una división clara del flujo de documentos por tiendas y la información de todas las tiendas de la red se consolida en el nodo RIB central. Usando el nodo central, puede crear rápidamente un nodo RIB periférico.

La solución de aplicación "1C: Retail 8" puede intercambiar información automáticamente con la administración sistema de informacion(back-office). como sistema de control de solución aplicada Se puede utilizar la solución de aplicación "1C: Retail 8" "Gestión comercial". Usando el sistema de control, puede crear un número ilimitado de nodos en la solución de aplicación 1C: Retail 8, que, a su vez, pueden ser los nodos centrales de una base de información distribuida.

Se proporcionan mecanismos para administrar usuarios de la base de información de nodos RIB remotos desde el nodo principal de la solución aplicada. Por ejemplo, en el nodo principal de la RIB, el administrador del sistema puede dar de alta un usuario de la infobase del nodo remoto y configurar sus derechos de acceso.

Junto con la contabilidad multitienda, se ha implementado la contabilidad multiempresa, donde cada almacén (piso comercial) puede asignarse a una organización específica (empresa).

La solución de aplicación "1C: Retail 8" puede utilizar esquemas de pedidos para el movimiento, venta y recepción de mercancías en los almacenes de las tiendas. El esquema de pedido prevé el registro preliminar de una lista de bienes necesarios para la aceptación o el envío desde el almacén, mientras que la operación real con bienes en el almacén se registra mediante los documentos "Pedido saliente de bienes" o "Pedido entrante de bienes".

La contabilidad de las existencias de productos básicos en los almacenes de las tiendas y la contabilidad de los fondos en las cajas de las tiendas están automatizadas.

La solución de la aplicación le permite ajustar los precios minoristas de cada tienda desde un nodo central. Al mismo tiempo, puede otorgar a la tienda el derecho de ajustar los precios minoristas por su cuenta, según su ubicación y la presencia de competencia.

El programa implementa mecanismos para la formación de etiquetas y etiquetas de precio.

Mecanismos implementados Detección automática Tasas de IVA en el momento de la venta de bienes de los almacenes de la tienda. El sistema de tributación se establece para cada almacén por separado. En el momento de la venta de los bienes, el cajero para la venta de los bienes y el grupo de nomenclatura al que pertenece (los bienes) determinan el piso de negociación (o almacén) desde el cual es necesario vender los bienes. Esto permite ingresar correctamente los documentos en las tiendas utilizando un sistema de impuestos mixto.

La solución de aplicación "1C: Retail 8" implementa esquemas para la distribución automatizada de mercancías entre almacenes, cuando, al recibir las mercancías, el operador puede distribuir el suministro entre los almacenes (pisos comerciales) de la tienda, según la nomenclatura del grupo de mercancías. .

En versiones anteriores de Linux (basadas en Red Hat) solo había dos formas de instalar el software. Esta es una compilación desde la fuente y la instalación desde paquetes RPM. Consideremos cada método con más detalle.

Los códigos fuente se descargan del sitio web del programa. En general, para instalar, debe descomprimir y ejecutar 3 comandos: configurar, hacer Y hacer instalar. El primer comando tiene muchas opciones (puede enumerarlas ejecutando configurar --ayuda), como la ruta de instalación del programa, rutas a varias bibliotecas y muchos otros. Después de completar con éxito la primera etapa, debe ejecutar el comando hacer. Compilará los códigos fuente en archivos binarios. Si la compilación fue exitosa, el último comando copiará los archivos compilados a sus directorios. La ventaja de este método de instalación es, en primer lugar, que el 99% de todos fuente abierta- los programas se distribuyen en códigos fuente, y es posible que el programa deseado no tenga un paquete RPM (ahora, sin embargo, el formato RPM se ha generalizado mucho y casi todos los desarrolladores intentan crear paquetes en este formato). En segundo lugar, siempre puede editar las fuentes del programa instalado, corregir el error o realizar los cambios necesarios. Solo hay una desventaja: para usar este método, debe conocer el lenguaje de programación c / c ++ y la arquitectura del sistema operativo. Por lo tanto, no todos pueden usar este método, especialmente si hay algún error.

La instalación desde un paquete RPM se realiza de la siguiente manera: debe descargar el paquete RPM y ejecutar solo un comando: rpm -Uvh ./nombre_paquete.rpm(Dónde paquete_nombre es el nombre del archivo del paquete). Este método no solo es mucho más fácil, sino también más rápido, ya que el programa ya está compilado en el paquete (puede llevar bastante tiempo compilar el programa, dependiendo de la potencia de su computadora). Sin embargo, el método tampoco es ideal, ya que a menudo sucede que un programa para su instalación requiere que también se instalen otros paquetes (por ejemplo, con las bibliotecas necesarias): aparecen las llamadas dependencias. Si un programa requiere una biblioteca, está bien, pero el programa puede requerir 10 o más bibliotecas, cada una de las cuales, a su vez, también puede requerir la instalación de bibliotecas. Por lo tanto, el tiempo de instalación del programa puede retrasarse mucho.

Sin embargo, en versiones recientes de Fedora, con la llegada de una utilidad de consola como yum, es un placer instalar programas. Para hacer esto, solo necesita escribir el siguiente comando en la consola: yum nombre de instalación(Dónde nombre- el nombre del programa a instalar). No solo eso mmm descargará el paquete necesario de Internet e instalará el programa, también descargará e instalará todos los programas necesarios para esto. Si no le gusta usar la consola, en KDE, por ejemplo, ejecute el programa desde el menú Sistema / Instalar / Desinstalar programas e instalar el programa usando la GUI.

Históricamente sucedió que el proceso de instalación de paquetes en diferentes distribuciones difiere significativamente. Y los propios paquetes de instalación tienen formato diferente. Este artículo será de utilidad para los usuarios de la distribución Fedora (Fuente).

Los códigos fuente se descargan del sitio web del programa. En general, para instalar, debe descomprimir y ejecutar 3 comandos: configurar, hacer Y hacer instalar. El primer comando tiene muchas opciones (puede enumerarlas ejecutando configurar -ayuda), como la ruta de instalación del programa, rutas a varias bibliotecas y muchos otros. Después de completar con éxito la primera etapa, debe ejecutar el comando hacer. Compilará los códigos fuente en archivos binarios. Si la compilación fue exitosa, el último comando copiará los archivos compilados a sus directorios. La ventaja de este método de instalación es, en primer lugar, que el 99% de todos los programas de código abierto se distribuyen en códigos fuente, y el programa deseado puede no tener un paquete RPM (ahora, sin embargo, el formato RPM se ha generalizado mucho y casi todos los desarrolladores intente crear paquetes en este formato). En segundo lugar, siempre puede editar las fuentes del programa instalado, corregir el error o realizar los cambios necesarios. Solo hay una desventaja: para usar este método, debe conocer el lenguaje de programación c / c ++ y la arquitectura del sistema operativo. Por lo tanto, no todos pueden usar este método, especialmente si hay algún error.

La instalación desde un paquete RPM se realiza de la siguiente manera: debe descargar el paquete RPM y ejecutar solo un comando: rpm -Uvh ./nombre_paquete.rpm(Dónde paquete_nombre es el nombre del archivo del paquete). Este método no solo es mucho más fácil, sino también más rápido, ya que el programa ya está compilado en el paquete (puede llevar bastante tiempo compilar el programa, dependiendo de la potencia de su computadora). Sin embargo, el método tampoco es ideal, ya que a menudo sucede que un programa para su instalación requiere que también se instalen otros paquetes (por ejemplo, con las bibliotecas necesarias); aparecen las llamadas dependencias. Si un programa requiere una biblioteca, está bien, pero el programa puede requerir 10 o más bibliotecas, cada una de las cuales, a su vez, también puede requerir la instalación de bibliotecas. Por lo tanto, el tiempo de instalación del programa puede retrasarse mucho.

Sin embargo, en versiones recientes de Fedora, con la llegada de una utilidad de consola como yum, es un placer instalar programas. Para hacer esto, solo necesita escribir el siguiente comando en la consola: yum nombre de instalación(Dónde nombre– el nombre del programa a instalar). No solo eso mmm descargará el paquete necesario de Internet e instalará el programa, también descargará e instalará todos los programas necesarios para esto. Si no le gusta usar la consola, en KDE, por ejemplo, ejecute el programa desde el menú Sistema / Instalar / Desinstalar programas e instalar el programa usando la GUI.

linuxfedora es una de las distribuciones más populares en la actualidad linux para probar nuevas tecnologías. Producto linuxfedora merecidamente ganó la confianza de los usuarios debido a una combinación de programas relevantes y estabilidad general. La distribución está enfocada a construir un sistema operativo completo a partir de software libre.

Proyecto linuxfedora es una base de prueba para una distribución comercial Rojo Empresa de sombreros linux: antes de incluir nuevas características en RHEL deben aparecer en Fedora. Cambios destinados a red hat empresa linux, Primero se prueban en esta distribución.

Solución linuxfedora diseñado para aquellos que prefieren trabajar con versiones avanzadas de programas. En el nuevo lanzamiento linux fedora 13, se han introducido muchas mejoras que afectan áreas como la configuración de periféricos, la localización al ruso y otros idiomas, el trabajo con cuentas de usuario, la instalación de un kit de distribución a través de Internet.

Nuevo en Linux Fedora 13

Integración completa con kit de paquete. Brasero ahora puede instalar automáticamente los códecs faltantes Gstreamer, si son necesarios para grabar CD de audio. rodillo de archivo instala los programas necesarios para procesar varios formatos de archivo;

Usar como administrador de fotos pozo de tiro en lugar de Pulgar Y punto f pozo de tiro- facil de manejar software libre gestión de fotos para entorno de escritorio GNOMO;

Trabajar con escaneo sencillo. Este programa Scan está diseñado para conectar un escáner y escanear una imagen o documento en un formato adecuado;

Instalación automática de controladores de impresión. Cuando se conecta en paralelo o Kit de paquete de impresora USB busca e instala el controlador correcto para el fabricante y el modelo.

Software incluido con Linux Fedora 13:

Configurador: una serie de utilidades gráficas para la configuración del sistema;

Entornos gráficos - KDE 4.4.2 se usa por defecto GNOMO 2.30.0;

aplicaciones de internet - Firefox 3.6.3, Thunderbird 3.0.4, Nautilus 2.30.1;

Aplicaciones de oficina - OpenOffice.org 3.2.0, Gimp 2.6.8;

Centro Linux - 2.6.33.3;

Programas para desarrolladores - Gcc 4.4.4, Glibc 2.12, GTK+ 2.20.1, Perl 5.10.1, PHP 5.3.1, Python 2.6.4, Qt-x11 4.6.2, NetBeans 6.8.;

Principales programas del servidor - Mysql 5.1.45, Postgresql 8.4.3, Postfix 2.7.0, Sendmail 8.14.4, Samba 3.5.2;

Programas para lanzar aplicaciones de windows - Vino.