Fedora RPM Guide - en to ro translation catalogue (149 entries)

note: Tag: title
en: Advanced RPM Packaging
ro: Creare avansată pachete RPM

note: Tag: para
en: This chapter covers:
ro: Acest capitol acoperă:

note: Tag: para
en: Defining package dependency information
ro: Se definește informația despre dependențele pachetelor

note: Tag: para
en: Setting triggers
ro: Setare trigger-e

note: Tag: para
en: Writing verification scripts
ro: Scriere scripturi de verificare

note: Tag: para
en: Creating subpackages
ro: Creare subpachete

note: Tag: para
en: Creating relocatable packages
ro: Creare pachete relocabile

note: Tag: para
en: Defining conditional builds
ro: Definire construcții condiționale

note: Tag: para
en: The previous chapter introduced the RPM spec file, which controls how RPM packages are built and installed. This chapter delves into advanced spec file topics such as using conditional commands and making relocatable packages, starting with how to specify package dependencies.
ro: Capitolul anterior a introdus fișierul spec RPM, care controlează cum sunt construite și instalate pachetele RPM. Acest capitol intră mai adânc în subiecte mai avansate despre fișiere spec cum ar fi utilizarea comenzilor condiționale și creare de pachete relocabile, începând cu instrucțiuni despre cum să specificați dependențele pachetelor

note: Tag: title
en: Defining Package Dependencies
ro: Definirea dependențelor pachetelor

note: Tag: para
en: Dependencies are one of the most important parts of the RPM system. The RPM database tracks dependencies between packages to better allow you to manage your system. A dependency occurs when one package depends on another. The RPM system ensures that dependencies are honored when upgrading, installing, or removing packages. From that simple concept, RPM supports four types of dependencies:
ro: Dependențele sunt una dintre cele mai importante părți ale sistemului RPM. Baza de date RPM caută dependențele între pachete pentru a vă permite să vă administrați sistemul mai bine. Dependențele apar când un pachet depinde de un altul. Sistemul RPM se asigură că dependențele sunt îndeplinite la actualizare, instalare sau la ștergerea pachetelor. Pornind de la acest concept simplu, RPM suportă patru tipuri de dependențe:

note: Tag: para
en: *Requirements, where one package requires a capability provided by another
ro: *Requirements (cerințe), unde un pachet cere o capabilitate asigurată de către alt pachet.

note: Tag: para
en: *Provides, a listing of the capabilities your package provides
ro: *Provides (asigură), o listă de capabilități asigurate de pachetul dvs.

note: Tag: para
en: *Conflicts, where one package conflicts with a capability provided by another
ro: *Conflicts (conflict), unde un pachet este în conflict cu o capabilitate asigurată de alt pachet

note: Tag: para
en: *Obsoletes, where one package obsoletes capabilities provided by another, usually used when a package changes name and the new package obsoletes the old name
ro: *Obsoletes (scos din uz), unde un pachet scoate din uz capabilitățiasigurate de un altul.

note: Tag: para
en: Cross Reference
ro: Referință încrucișată

note: Tag: para
en: <xref linkend="ch-dependencies" /> covers more on dependencies. The Obsoletes dependencies are usually only used when a package is renamed, such as the apache package becoming the httpd package, starting in Red Hat Linux 8.0. The httpd package obsoletes the apache package.
ro: <xref linkend="ch-dependencies" /> are mai multe informații despre dependențe.Dependențele tip obsoletes sunt folosite de obicei doar când un pachet este redenumit, ca de exemplu pachetul apache care a devenit httpd, începând cu Red Hat Linux 8.0. Pachetul httpd scoate din uz pachetul apache.

note: Tag: para
en: You can list all of these dependencies in your spec file. The most commonly used dependency information, though, is what a package requires.
ro: Puteți enumera toate dependențele în fișierul dvs. spec. Cea mai folosită informație legată de dependențe este cea legată de cerințele unui pachet.

note: Tag: title
en: Naming dependencies
ro: Numirea dependențelor

note: Tag: para
en: In your spec files, you can name the dependencies for your package. The basic syntax is:
ro: În fișierele dvs. spec puteți numi dependențele pentru pachetul dvs. Sintaxa de bază este:

note: Tag: para
en: Requires: capability
ro: Requires: capabilitate

note: Tag: para
en: In most cases, the capability should be the name of another package. This example sets up a requires dependency. This means that the package requires the given capability. Use a similar syntax for the other kinds of dependencies:
ro: În cele mai multe cazuri, capabilitatea ar trebui să fie numele unui alt pachet. Acest exemplu setează o dependență de tip requires. Acest lucru înseamnă că pachetul cere acea capabilitate. Folosiți o sintaxă asemănătoare și la alte tipuri de dependențe:

note: Tag: para
en: Provides: capability
ro: Provides: capabilitate

note: Tag: para
en: Obsoletes: capability
ro: Obsoletes: capabilitate

note: Tag: para
en: Conflicts: capability
ro: Conflicts: capabilitate

note: Tag: para
en: You can put more than one capability on the dependency line. For example:
ro: Puteți pune mai mult de o singură capabilitate pe linia cu dependențele. De exemplu:

note: Tag: para
en: You can use spaces or commas to separate the capabilities. For example:
ro: Puteți folosi spații sau virgule pentru a separa capabilitățile. De exemplu:

note: Tag: title
en: Specifying the Version of the Dependencies
ro: Specificarea versiunii dependențelor

note: Tag: para
en: You can also add version information, for example:
ro: Puteți adăuga și informații despre versiune, de exemplu:

note: Tag: para
en: This states that the package requires the capability bash (a package) at version 2.0 or higher. The same logic applies to the other types of dependencies. For example:
ro: Aceasta înseamnă că pachetul cere capabilitatea bash (un pachet) cu versiunea 2.0 sau mai sus. Aceeași logică se aplică la alte tipuri de dependențe.Spre exemplu:

note: Tag: para
en: This example states that the package conflicts with all versions of bash 2.0 or higher.
ro: Acest exemplu arată că pachetul este în conflict cu toate versiunile bash 2.0 sau mai recente

note: Tag: para
en: Table 11-1 lists the version comparisons you can use.
ro: Tabelul 11-1 enumerează comparațiile de versiuni pe care le puteți folosi.

note: Tag: para
en: Table 11-1 Dependency version comparisons
ro: Tabel 11-1 Comparații de versiuni dependențe

note: Tag: para
en: Comparison
ro: Comparație

note: Tag: para
en: Meaning
ro: Semnificație

note: Tag: para
en: package &lt; version
ro: pachet &lt; versiune

note: Tag: para
en: A package with a version number less than version
ro: Un pachet de versiune mai veche

note: Tag: para
en: package &gt; version
ro: pachet &gt; versiune

note: Tag: para
en: A package with a version number greater than version
ro: Un pachet de versiune mai nouă

note: Tag: para
en: package &gt;= version
ro: pachet &gt;= versiune

note: Tag: para
en: A package with a version number greater than or equal to version
ro: Un pachet de versiune mai nouă sau la fel

note: Tag: para
en: package &lt;= version
ro: pachet &lt;= versiune

note: Tag: para
en: A package with a version number less than or equal to version
ro: Un pachet de versiune mai veche sau la fel

note: Tag: para
en: package = version
ro: pachet = versiune

note: Tag: para
en: A package with a version number equal to version
ro: Un pachet de versiune egală

note: Tag: para
en: package
ro: pachet

note: Tag: para
en: A package at any version number
ro: Pachet la orice versiune

note: Tag: para
en: RPM supports an extended version number syntax for comparisons. The full format follows:
ro: RPM suportă o sintaxă extinsă pentru compararea versiunilor. Acesta esteformatul complet:

note: Tag: para
en: Epoch:Version-Release
ro: Perioadă:Versiune-Lansare

note: Tag: para
en: For example:
ro: De exemplu:

note: Tag: para
en: In this case, the epoch is 1, the version 5.6.0, and the release is 17. In most cases, you will need just the version number. The epoch allows for handling hard-to-compare version numbers. The release number is almost never used. This makes sense, in that it ties a dependency to a particular build of the RPM package, rather than a version of the software itself. This type of dependency would only be useful if you drastically changed the way you build a package.
ro: În acest caz, perioada este 1, versiunea este 5.6.0 iar lansarea este 17.În cele mai multe cazuri veți avea nevoie doar de versiune. Perioada permitemanevrarea versiunilor greu de comparat. Numărul de lansare nu este folosit aproape niciodată. Acest lucru are sens pentru că leagă o dependență de o anumităconstrucție a pachetului RPM mai degrabă decât de o versiune a programului în sine.Acest tip de dependență poate fi de folos doar dacă schimbați radical modul deconstrucție al unui pachet.

note: Tag: title
en: Creating Virtual CAPABILITIES
ro: Creare CAPABILITIES virtuale

note: Tag: para
en: Dependencies are based on capabilities, most of which are packages. You can create virtual capabilities, which are just names you define. For example, the sendmail package provides a virtual capability named smtpdaemon. For example:
ro: Dependențele sunt bazate pe capabilități, cele mai multe dintre acestea fiindpachete. Puteți crea capabilități virtuale, care sunt doar nume definite de dvs.De exemplu, pachetul sendmail asigură o capabilitate virtuală numită smtpdaemon.De exemplu:

note: Tag: para
en: This capability refers to the general SMTP Internet service for sending e-mail messages. There is no file of this name. Instead, it is just a capability, arbitrary text. Other packages require this capability, such as the fetchmail mail-retrieval and forwarding application, and mutt, an e-mail client program.
ro: Această capabilitate se referă la serviciul general SMTP pentru trimitereamesajelor e-mail. Nu există un fișier cu acest nume. Este doar o capabilitate,text arbitrar. Alte pachete cer această capabilitate, cum ar fi aplicațiafetchmail de descărcare și forwardare e-mail, și mutt, un client de mail.

note: Tag: para
en: By using a virtual capability, other packages can provide the capability, and most importantly, client applications can require the capability without worrying which package provides the ability to send e-mail messages. For example, the exim and postfix packages, mail transport agents like sendmail, can provide the same capability.
ro: Prin folosirea unei capabilități virtuale, alte pachete pot asigura capabilitatea, și, cel mai important, aplicațiile client pot cere această capabilitate fără a trebui să știe ce pachet asigură capabilitatea de a trimite mesaje e-mail. De exemplu, pachetele exim și postfix, agenți de transport mail ca și sendmail, pot asiguraaceeași capabilitate.

note: Tag: para
en: Note
ro: Notă

note: Tag: para
en: Of course, you want to ensure that these packages specify that they conflict with each other.
ro: Desigur, veți dori să vă asigurați că aceste pachete intră în conflict unelecu altele.

note: Tag: title
en: Naming Dependencies on Script Engines and Modules
ro: Numirea dependențelor în motoare de scripting și module

note: Tag: para
en: Scripting languages such as Perl and Tcl allow for add-on modules. Your package may require some of these add-on modules. RPM uses a special syntax with parenthesis to indicate script module dependencies. For example:
ro: Limbaje de scripting ca Perl sau Tcl permit module adiționale. Pachetul dvs. poate avea nevoie de unele dintre aceste module. RPM folosește o sintaxă specialăcu paranteze pentru a indica dependențe de module de scripting. De exemplu:

note: Tag: para
en: This indicates a requirement for the Carp add-on module for Perl, greater than or equal to version 3.2.
ro: Aceasta indică o cerere pentru modulul adițional Carp pentru Perl, cu o versiune mai recentă sau egală cu 3.2.

note: Tag: title
en: Setting prerequisites
ro: Setarea premiselor

note: Tag: para
en: A prerequisite is similar to a require dependency, except that a prerequisite must be installed prior to a given package. Specify a prerequisite as follows:
ro: O premisă este similară cu o dependență require, doar că o premisătrebuie instalată înainte de un anume pachet. Specificați o premisă după cum urmează:

note: Tag: para
en: You can include version-number dependencies, such as:
ro: Puteți include dependențe cu număr-versiune, cum ar fi:

note: Tag: para
en: In most usage, a PreReq: acts just like Requires:, in fact, the PreReq: directive exists just to allow for a manual order to dependencies. RPM guarantees that the PreReq: package will be installed prior to the package that names the PreReq: dependency.
ro: De obicei, o PreReq: se comportă ca o Requires:, de fapt, directiva PreReq:există doar pentru a permite ordonarea manuală a dependențelor. RPM garantează că pachetul PreReq: va fi instalat înainte de pachetul care numește dependențaPreReq: .

note: Tag: para
en: <xref linkend="ch-packaging-guidelines" /> covers a common problem of handling circular dependencies using prerequisites.
ro: <xref linkend="ch-packaging-guidelines" /> descrie problema comună detratare a dependențelor circulare folosind premise.

note: Tag: title
en: Naming build dependencies
ro: Numirea dependențelor de construcție

note: Tag: para
en: Your package, once built, has a set of dependencies. These dependencies are important for anyone installing the package. But there are also dependency issues when trying to build packages. Build dependencies allow you to specify what is necessary to build the package. While you may think this would be the same as what is needed to install a package, this is normally not true. Linux distributions tend to divide up software into runtime and development packages. For example, the python package contains the runtime for executing scripts written in Python. The python-devel package provides the ability to write extensions to the Python language.
ro: Pachetul dvs., odată construit, are un set de dependențe. Aceste dependențe sunt importante pentru oricine care instalează pachetul. Dar există și probleme cu dependențele la construirea pachetelor. Dependențele de construcție vă permit să precizați de ce este nevoie pentru a construi pachetul. Chiar dacă credeți că acest lucru e același cu ce este necesar pentru a instala pachetul, în mod normal nu este așa. Distribuțiile de Linux tind să împartă software-ul în pachete necesare la rulare și pachete pentru dezvoltatori (runtime și development)De exemplu, pachetul python conține runtime-ul necesar pentru executarea scripturilorscrise în Python. Pachetul python-devel asigură abilitatea de a scrie extensii ale limbajului Python

note: Tag: para
en: RPM allows you to define build-time dependencies in your spec files using the following directives:
ro: RPM vă permite să definiți dependențe în timpul construirii în fișierele dvs. spec folosind următoarele directive:

note: Tag: para
en: These directives act like Requires:, Conflicts:, and PreReq:, respectively, except that the dependencies are needed to build the package, not install it. For example, your package may require a C compiler to build, or may need a special build tool or developer library.
ro: Aceste directive se comportă ca Requires:, Conflicts:, respectiv PreReq:, exceptând faptul că dependențele sunt necesare pentru construirea pachetului, nu pentru instalarea lui. De exemplu, pachetul dvs. poate avea nevoie de un compilator C pentru construcție, sau ar putea avea nevoie de un instrument special de construit sau o bibliotecă de dezvoltare

note: Tag: title
en: Generating dependencies automatically
ro: Generarea automată de dependențe

note: Tag: para
en: Because so many dependencies are related to shared libraries, the RPM system will automatically generate provide dependencies for any file in your packages that is a shared object, or .so, file. RPM will also automatically generate require dependencies for all files in the %files list that require shared libraries. To do this, RPM uses the ldd command, which determines the shared libraries used by an application.
ro: Pentru că multe dependențe sunt legate de bibliotecile shared, sistemul RPM  va genera automat dependențe provide pentru orice fișier din pachetele dvs.care este obiect shared sau fișier .so. RPM va genera de asemenea dependențerequire pentru toate fișierele din lista %files care cer biblioteci shared.Pentru a realiza acest lucru, RPM folosește comanda ldd, care determină bibliotecile shared folosite de o aplicație.

note: Tag: para
en: In addition, the find-requires and find-provides scripts in /usr/lib/rpm can determine Perl, Python and Tcl script dependencies and other dependencies, such as Java package dependencies, automatically. The find-requires script determines requires dependencies automatically, and the find-provides script determines provides dependencies.
ro: în plus, scripturile find-requires și find-provides din /usr/lib/rpm pot  determina dependențele scripturilor Perl, Python și Tcl și alte dependențe,cum ar fi dependențele pachetelor Java, în mod automat. Scriptul find-requiresdetermină dependențele requires automat, iar scriptul find-provides determină dependențele provides

note: Tag: para
en: <xref linkend="ch-packaging-guidelines" /> covers how to turn off the automatic generation of dependencies.
ro: <xref linkend="ch-packaging-guidelines" /> tratează oprirea generării automate a dependențelor.

note: Tag: title
en: Setting Triggers
ro: Setarea triggerelor

note: Tag: para
en: Triggers provide a way for one package to take action when the installed status of another package changes. A trigger is a script you define in your package’s spec file that gets run by the RPM system when the status of another named package changes. If your package depends in some way on another package, a trigger can allow your package to deal with changes to the other package.
ro: Triggerele oferă posibilități unui pachet de a acționa când statusul de instalare al altui pachet se schimbă. Un trigger este un script pe care îl definiți în fișierul spec al pachetului dvs. care este rulat de sistemulRPM când statusul unui anume pachet se schimbă. Dacă pachetul dvs. depindeîntr-un anume fel de alt pachet, un trigger poate permite pachetului dvs. săse ocupe de schimbările din celălalt pachet

note: Tag: para
en: Triggers are not a replacement for package dependencies. Instead, triggers are useful when you need to change a package’s installation based on other packages installed on the system. For example, if your package is a mail client program, your package will need to have a mail transfer agent, or MTA. Linux supports a number of different mail transfer agents, such as sendmail, vmail, exim, qmail, and postfix.
ro: Triggerele nu sunt un înlocuitor pentru dependențele pachetelor. În schimb,triggerele sunt folositoare când doriți să schimbați instalarea unui pachetîn funcție de alte pachete instalate. De exemplu, dacă pachetul dvs. este unclient de mail, pachetul dvs. va avea nevoie de un agent de transfer mail, sauMTA. Linux suportă mai mulți agenți de transfer mail, cum ar fi sendmail, vmailexim, qmail și postfix

note: Tag: para
en: Typically a system will have one mail transfer agent installed. In most cases, a mail client won’t care which MTA is installed, as long as one is installed. (In fact, most of these packages should be marked that they conflict with one another, ensuring that a given system can only have one.)
ro: În mod uzual un sistem va avea un agent de transfer mail instalat. În cele mai multe cazuri, pentru un client de mail nu va conta ce MTA este instalat,atâta timp cât există. (De fapt, mare parte din aceste pachete ar trebui marcate ca fiind în conflict, asigurându-ne astfel că un sistem dat poateavea doar unul.)

note: Tag: para
en: The %triggerin script is run when a given target package is installed or upgraded. The %triggerin script is also run when your package is installed or upgraded, should the target package be already installed. Similarly, the %triggerun script is run if the target package is removed. It is also run if your package is removed and the target package is installed. The %triggerpostun script is run after the target package has been removed. It is not run if your package is removed.
ro: Scriptul %triggerin este rulat când un anume pachet-țintă este instalat sau actualizat. Scriptul %triggerin este de asemenea rulat când pachetul dvs esteinstalat sau actualizat, cu condiția ca pachetul-țintă să fie deja instalat.La fel, scriptul %triggerun este rulat dacă pachetul-țintă este dezinstalat.Este de asemenea rulat dacă pachetul dvs. este dezinstalat și pachetul-țintăeste instalat. Scriptul %triggerpostun este rulat după ce pachetul-țintă a fostdezinstalat. Nu este rulat dacă pachetul dvs. este dezinstalat.

note: Tag: para
en: To define one of these scripts, you need to list the name of the target package; for example:
ro: Pentru a defini unul dintre aceste  scripturi, este necesar să specificaținumele pachetului-țintă; de exemplu:

note: Tag: para
en: script commands...
ro: comenzi script...

note: Tag: para
en: This example sets up a trigger for the tcsh package. If the tcsh package is installed or upgraded, RPM will run the script. If your package is installed or upgraded and the tcsh package is presently installed, RPM will also run the script.
ro: Acest exemplu setează un trigger pentru pachetul tcsh. Dacă pachetul tcsh este instalat sau actualizat, RPM va rula scriptul. Dacă pachetul dvs. este instalat sau actualizat și pachetul tcsh este instalat, RPM de asemenea va rula scriptul.

note: Tag: para
en: Define the %triggerun script similarly:
ro: Definiți scriptul %triggerun în mod similar:

note: Tag: para
en: %triggerun -- tcsh
ro: triggerun -- tcsh

note: Tag: para
en: You can also use version numbers in the trigger script definition to only run the script in the case of a particular version. For example:
ro: Puteți folosi de asemenea numere de versiune în definiția scriptului triggerpentru a rula scriptul doar în cazul unei anumite versiuni. De exemplu:

note: Tag: para
en: This example, from the vixie-cron scheduling package, runs a post-uninstall trigger for the same package, but for older versions. To define trigger scripts for particular versions, use the same syntax as for requires dependencies for naming the version number and comparisons.
ro: Acest exemplu, din pachetul de planificare vixie-cron, rulează un triggerpost-uninstall (postdezinstalare) pentru același pachet, dar pentru versiunimai vechi. Pentru a defini scripturi trigger pentru versiuni specifice, folosiți aceeași sintaxă ca pentru dependențele requires la stabilirea versiunii și a comparațiilor.

note: Tag: para
en: Triggers are run through /bin/sh, the most commonly used shell script engine. With the -p option, though, you can specify a different script interpreter. For example, to write a Perl script, define your trigger like the following:
ro: Triggerele sunt rulate prin /bin/sh, cel mai folosit motor de shell scripting. Folosind opțiunea -p totuși, puteți specifica un alt interpretor de scripting. De exemplu, pentru a scrie un script Perl, definiți triggerulca mai jos:

note: Tag: para
en: With subpackages, defined following, you can use a -n option to tie the trigger script to a subpackage. For example:
ro: Prin subpachete, definite în cele ce urmează, puteți folosi o opțiune -npentru a lega scriptul trigger de un subpachet. De exemplu:

note: Tag: para
en: Inside your trigger scripts, $1, the first command-line argument, holds the number of instances of your package that will remain after the operation has completed. The second argument, $2, holds the number of instances of the target package that will remain after the operation. Thus, if $2 is 0, the target package will be removed.
ro: În scripturile dvs trigger, $1, primul argument al liniei de comanda, conține numărul de instanțe ale pachetului dvs. care vor rămâne după completarea operațiunii.Al doilea argument, $2, conține numărul de instanțe ale pachetului-țintă care vor rămâne după operațiune. Astfel, dacă $2 e 0, pachetul-țintă va fi dezinstalat.

note: Tag: para
en: The anonftp package, mentioned in <xref linkend="ch-dependencies" /> , has a lot of triggers. Many of these set up a number of commands to be locally available to the anonftp package. This networking package is also closely tied to the version of the C library, glibc, as shown in Listing 11-1
ro: Pachetul anonftp, menționat în <xref linkend="ch-dependencies" />, are multe triggere. Multe dintre ele fac disponibile mai multe comenzi pentru pachetul anonftp. Acest pachet de rețea este de asemenea legat strâns de versiunea bibliotecii de C, glibc, după cum se vede în lista 11-1

note: Tag: para
en: Listing 11-1: Anonftp package trigger scripts.
ro: Lista 11-1: Scripturile trigger ale pachetului anonftp.

note: Tag: para
en: %triggerin -- glibc
ro: triggerin -- glibc

note: Tag: para
en: # Kill off old versions
ro: # Terminare versiuni mai vechi

note: Tag: para
en: # Copy parts of glibc, needed by various programs in bin.
ro: # Părți copie din glibc, de care este nevoie în bin.

note: Tag: para
en: copy /lib/ld-${LIBCVER}.so /var/ftp/lib
ro: copiere /lib/ld-${LIBCVER}.so /var/ftp/lib

note: Tag: para
en: copy /lib/libc-${LIBCVER}.so /var/ftp/lib
ro: copiere /lib/libc-${LIBCVER}.so /var/ftp/lib

note: Tag: para
en: copy /lib/libnsl-${LIBCVER}.so /var/ftp/lib
ro: copiere /lib/libnsl-${LIBCVER}.so /var/ftp/lib

note: Tag: para
en: copy /lib/libnss_files-${LIBCVER}.so /var/ftp/lib
ro: copiere /lib/libnss_files-${LIBCVER}.so /var/ftp/lib

note: Tag: para
en: # Use ldconfig to build symlinks and whatnot.
ro: # Folosiți ldconfig pentru a construi legături simbolice și așa mai departe.

note: Tag: para
en: copy /bin/ls /var/ftp/bin
ro: copiere /bin/ls /var/ftp/bin

note: Tag: para
en: copy /bin/cpio /var/ftp/bin
ro: copiere /bin/cpio /var/ftp/bin

note: Tag: para
en: copy /bin/tar /var/ftp/bin
ro: copiere /bin/tar /var/ftp/bin

note: Tag: para
en: copy /bin/gzip /var/ftp/bin
ro: copiere /bin/gzip /var/ftp/bin

note: Tag: para
en: copy '/lib/libtermcap.so.*.*.*' /var/ftp/lib
ro: copiere '/lib/libtermcap.so.*.*.*' /var/ftp/lib

note: Tag: para
en: copy /usr/bin/compress /var/ftp/bin
ro: copiere /usr/bin/compress /var/ftp/bin

note: Tag: para
en: # The user has multiple glibc packages installed. We can't read the
ro: # Utilizatorul are mai multe pachete glibc instalate. Nu putem citi

note: Tag: para
en: # user's mind, so don't do anything.
ro: # mintea utilizatorului, deci nu se va face nimic.

note: Tag: para
en: # Generate md5sums for verifyscript
ro: # Generare md5sum pentru verifyscript (script de verificare)

note: Tag: title
en: Writing Verification Scripts
ro: Scrierea scripturilor de verificare

note: Tag: para
en: RPM automatically handles package verification, checking to see that the proper files are installed, and testing the files themselves for the proper size and other attributes. You may need to do more in your package, though, to ensure everything is properly set up. With RPM, you can:
ro: RPM tratează automat verificarea pachetelor, controlând instalarea fișierelor corespunzătoare și testarea fișierelor pentru mărimea potrivită și alte atribute. S-ar putea să aveți nevoie de mai mult totuși pentru a vă asigura că totul este în regulă. Cu RPM, puteți:

note: Tag: para
en: *Control the tests used to verify each file, as described in <xref linkend="ch-specfiles" />
ro: *Controlați testele folosite la verificarea fiecărui fișier, așa ca în<xref linkend="ch-specfiles" />

note: Tag: para
en: *Create a verify script that performs other tests
ro: *Creați un script de verificare care efectuează alte teste

note: Tag: para
en: If you need to perform some other test to verify your package, such as check that a configuration file has a particular setting (and that the setting is valid), you can fill in the %verifyscript in the spec file. The %verifyscript acts much like the %pre or %post scripts, except that the %verifyscript gets executed during package verification. Fill in a %verifyscript as follows:
ro: Dacă doriți să efectuați alt test pentru a verifica pachetul, ca de exemplu să verificați dacă un fișier de configurare conține o anume setare (și că acea setare este validă), puteți completa %verifyscript în fișierul spec. %verifyscript se comportă în mare parte ca și scripturile %pre sau %post, cu diferența  că %verifyscript este executat în timpul verificării pachetului. Completați un %verifyscript după cum urmează:

note: Tag: para
en: Common %verifyscript actions are to check for an entry in a system configuration file, such as an init-time startup script or /etc/shells (which lists the available shells). These are files owned by other packages that may need to be properly modified for a package to be properly installed. If your package has a similar circumstance, write a %verifyscript. In your script, send all error output to stderr.
ro: Acțiuni comune pentru %verifyscript ar fi verificarea unei intrări într-un fișier de configurare a sistemului, ca de exemplu un script de pornire în timpul init sau /etc/shells (care listează shellurile disponibile). Acestea sunt fișiere care aparțin altor pachete care ar putea trebui modificate corespunzător pentru ca un pachet să fie instalat cum trebuie. Dacă pachetul este într-o asemenea situație, scrieți un %verifyscript. În scriptul dvs, direcționați toate erorile spre stderr.

note: Tag: para
en: See <xref linkend="ch-using-rpm-db" /> for more on package verification.
ro: A se vedea <xref linkend="ch-using-rpm-db" /> pentru detalii despre verificarea pachetelor.

note: Tag: title
en: Creating Subpackages
ro: Crearea subpachetelor.

note: Tag: para
en: A spec file may define more than one package. This type of additional package is called a subpackage. Subpackages exist to handle cases where you don’t want to associate one spec file with one package. Instead, you can define multiple packages within the spec file, as needed. For example, you may want to build the runtime and developer packages together, or the client and server portions of an application using subpackages. Splitting large documentation sets into separate subpackages is also common.
ro: Un fișier spec poate defini mai multe pachete. Aceste pachete adiționale se numesc subpachete. Subpachetele există pentru a trata cazuri în care nu doriți să asociați un fișier spec cu un pachet. În schimb, puteți defini mai multe pacheteîn fișierul spec, după caz. De exemplu, poate doriți să construiți pachetele runtimeși developer împreună, sau părțile client și server al eunei aplicații folosind subpachete. De asemenea, împărțirea seturilor de documentație mari în subpachete separate este o operațiune comună.

note: Tag: para
en: With subpackages, you get:
ro: Folosind subpachete, aveți:

note: Tag: para
en: *One spec file
ro: *Un fișier spec

note: Tag: para
en: *One source RPM
ro: *Un pachet RPM sursă

note: Tag: para
en: *One set of build commands
ro: *Un set de comenzi de construcție

note: Tag: para
en: *Multiple binary RPMs, one per package or subpackage
ro: *Pachete RPM binare multiple, câte unul per pachet sau subpachet

note: Tag: para
en: In most cases, subpackages are created just as a means to partition the files produced by a package into separate packages. For example, you will often see development libraries and header files split into a separate package from the main application package. Sometimes documentation is split out into a separate package, or client and server applications are divided into separate packages. In the end, though, this usually results in shifting files into subpackages and nothing more.
ro: În majoritatea cazurilor, subpachetele sunt create doar ca mijloc de a divide fișierele produse de un pachet în pachete separate. De exemplu, veți observa de multe ori biblioteci de development și fișiere headersunt separate într-un pachet diferit de pachetul principal al aplicației.Câteodată documentația este despărțită de pachetul principal, sau aplicațiile client și server sunt împărțite în pachete separate. Până la urmă acest faptrezultă în mutarea fișierelor în subpachete și nimic mai mult.

note: Tag: para
en: To define a subpackage within a spec file, you start with the %package directive. For example:
ro: Pentru a defini un subpachet într-un fișier spec, începeți cu directiva %package. De exemplu:

note: Tag: para
en: %package sub_package_name
ro: %package nume_subpachet

note: Tag: para
en: By default, the name of the subpackage will be the name of the package, a dash, and the subpackage name provided with the %package directive. For example:
ro: În mod implicit numele subpachetului va fi numele pachetului, o liniuță și numele subpachetului așa cum apare în directiva %package. De exemplu:

note: Tag: para
en: This example names a subpackage server, which is a real subpackage inside the telnet package. In this case, the name for the server subpackage will be telnet-server, that is, the naming format is package-subpackage.
ro: Acest exemplu denumește un subpachet server care este un subpachet real inclusîn pachetul telnet. În acest caz, numele subpachetului server va fi telnet-server, adică formatul de nume este pachet-subpachet.

note: Tag: para
en: If you don’t want this naming format, you can use the –n option to the %package directive to define an entirely new name, using the following syntax:
ro: Dacă nu doriți acest format de nume, puteți folosi opțiunea -n a directivei %package pentru a defini un nume complet nou, folosindurmătoarea sintaxă:

note: Tag: para
en: %package -n new_sub_package_name
ro: %package -n nume_nou_subpachet

note: Tag: para
en: With the –n option, you specify the full name for the subpackage. The RPM system will not prefix the name with the enclosing package name.
ro: Cu opțiunea -n puteți specifica numele întreg al subpachetului. Sistemul RPM nu va prefixa numele cu cel al pachetului care îl include.

note: Tag: title
en: Providing information for subpackages
ro: Furnizarea informațiilor pentru subpachete

note: Tag: para
en: When you define a subpackage, you need to provide as many of the package information directives as you need, including at the least Summary:, Group:, and %description directives. Anything not specified will use the parent package’s value, such as the version. Place these directives after the %package directive. For example:
ro: La definirea unui subpachet trebuie să furnizați atâtea directive legate de informații despre pachet câte aveți nevoie, incluzând cel puțin directivele Summary:,Group:, și %description.

note: Tag: para
en: Summary: The server program for the telnet remote login protocol.
ro: Sumar: Partea server pentru protocolul de login la distanță telnet

note: Tag: para
en: The %description directive for subpackages requires the name of the subpackage using the following syntax:
ro: Directiva %description pentru subpachete necesită numele subpachetuluifolosind următoarea sintaxă

note: Tag: para
en: %description subpackage
ro: %description subpachet

note: Tag: para
en: Telnet is a popular protocol for logging into remote systems
ro: Telnet este un protocol popular pentru logarea la sisteme la distanță

note: Tag: para
en: over the Internet. The telnet-server package includes a telnet daemon that supports remote logins into the host machine. The
ro: via internet. Pachetul telnet-server include un daemon telnet care suportă login la distanță la mașina gazdă.

note: Tag: para
en: telnet daemon is enabled by default. You may disable the telnet
ro: Daemonul telnet este activat implicit. Puteți dezactiva

note: Tag: para
en: daemon by editing /etc/xinetd.d/telnet.
ro: daemonul telnet prin editarea /etc/xinetd.d/telnet.

note: Tag: para
en: If you used the –n option with the %package directive, you need to repeat the –n option with the %description directive. For example:
ro: Dacă ați folosit opțiunea -n cu directiva %package, trebuie să repetațiopțiunea -n cu directiva %description. De exemplu:

note: Tag: para
en: The same concept works for the %files section. You need a separate %files section for each subpackage. For example:
ro: Același concept funcționează la secțiunea %files. Aveți nevoie de o secțiune%files separată pentru fiecare subpachet. De exemplu:

note: Tag: para
en: Again, if you used the –n option with the %package directive, you need to repeat the –n option with the %files section. For example:
ro: Din nou, dacă ați folosit opțiunea -n cu directiva %package, trebuie să repetați opțiunea -n cu secțiunea %files. De exemplu:

note: Tag: title
en: Defining scripts for subpackages
ro: Definirea scripturilor pentru subpachete

note: Tag: para
en: Much as you define separate %files and %description sections for subpackages, you can also define install and uninstall scripts for subpackages. The syntax is similar to that for the %files and %description sections:
ro: Așa cum definiți secțiuni %files și %description separate pentru subpachete, la fel puteți defini scripturi install si uninstallpentru subpachete. Sintaxa e asemănătoare cu cea pentru secțiunile%files și %description:

note: Tag: para
en: %pre subpackage
ro: %pre subpachet

note: Tag: para
en: For example, Listing 11-2 shows the scripts from the VNC package.
ro: De exemplu, Lista 11-2 afișează scripturile de la pachetul VNC.

note: Tag: para
en: Listing 11-2: VNC package install and uninstall scripts.
ro: Lista 11-2: scripturile install și uninstall pentru pachetul VNC.

note: Tag: title
en: Building subpackages
ro: Construirea subpachetelor

note: Tag: para
en: The build sections in the spec file serve double duty. These sections are used for building the main package as well as subpackages. This is one reason why there are so many options on the %setup macro.
ro: Secțiunile build din fișierul spec servesc un dublu scop. Aceste secțiunisunt folosite pentru construirea pachetului principal precum și a subpachetelor.Este unul din motivele pentru care există atâtea opțiuni în macroul %setup.

note: Tag: para
en: The %setup macro allows for selectively unpacking the sources, rather than the default option of unpacking all the sources. For example, the following %setup macro definition gives rpmbuild specific instructions for unpacking one source file:
ro: Macroul %setup permite despachetarea selectivă a surselor, în contrast cu opțiunea implicită de a despacheta toate sursele. De exemplu, definiția macroului %setup următor dă comenzii rpmbuild instrucțiuni specifice pentru despachetarea unui fișier sursă:
