| 1176 |
mateusz.vi |
1 |
|
|
|
2 |
Arquivos de pacote proveem uma forma fácil de gerenciar software no SvarDOS.
|
|
|
3 |
Esses pacotes devem aderir a uma convenção estrita, assim podem ser manipulados
|
|
|
4 |
corretamente pelo gerenciador de pacotes do SvarDOS.
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
%hNomes de arquivo de pacotes
|
|
|
8 |
|
|
|
9 |
Os nomes dos pacotes devem seguir algumas regras básicas. Devem ser de no máximo
|
|
|
10 |
8 tetras de tamanho (mas não devem ser muito curtos também, pois um pacote com 1
|
|
|
11 |
ou 2 letras no nome pode ser confuso), e não deve ser composto por caracters que
|
|
|
12 |
não sejam a-b, 0-9 e '_'. Isso é para compatibilidade com o padrão de nomes de
|
|
|
13 |
arquivo curtos (8+3) e sistemas de arquivo ISO 9660 (usados em CDROMs). O nome
|
|
|
14 |
de arquivo do pacote sempre é seguido da extensão .SVP ("SvarDOS Package").
|
|
|
15 |
|
|
|
16 |
|
|
|
17 |
%hArquivos de pacote
|
|
|
18 |
|
|
|
19 |
O SvarDOS usa arquivos ZIP como formato de arquivo de pacote. Esse formato foi
|
|
|
20 |
escolhido porque arquivos ZIP no DOS se tornaram de fato a maneira padrão para
|
|
|
21 |
distribuir coleções de arquivos. Além disso, o formato de arquivo ZIP é bem
|
|
|
22 |
documentado, bem suportado e em domínio público.
|
|
|
23 |
|
|
|
24 |
Abaixo está a linha de comando recomendada que pode ser usada para criar um
|
|
|
25 |
pacote para um programa chamado EXEMPLO usando info-zip:
|
|
|
26 |
|
|
|
27 |
zip -9rkDX EXEMPLO.SVP subdir1 subdir2 ... subdirN
|
|
|
28 |
|
|
|
29 |
Se você estiver usando o 7za (7-ZIP) para cirar seus pacotes, então use isso:
|
|
|
30 |
|
|
|
31 |
7za a -mm=deflate -mx=9 -tzip EXEMPLO.SVP subdir1 subdir2 ... subdirN
|
|
|
32 |
|
|
|
33 |
|
|
|
34 |
%hEstrutura de diretórios dos pacotes
|
|
|
35 |
|
|
|
36 |
A estrutura de diretórios de um pacote depende do tipo do pacote.
|
|
|
37 |
Para os pacotes "core", nós temos isso:
|
|
|
38 |
|
|
|
39 |
APPINFO Ponha o arquivo LSM do programa aqui
|
|
|
40 |
BIN Binários, tais como aquivos exe e com
|
|
|
41 |
DOC\PKGNAME Documentação do pacote
|
|
|
42 |
HELP Usado SOMENTE pelo pacote "help"
|
|
|
43 |
NLS\PKGNAME Traduções (arquivos de linguagem NLS) do pacote
|
|
|
44 |
|
|
|
45 |
Pacotes não-core usam uma organização de diretórios levemente diferente. Por
|
|
|
46 |
exemplo, se se formos considerar um pacote chamado FOO, podemos terminar com a
|
|
|
47 |
seguinte estrutura:
|
|
|
48 |
|
|
|
49 |
APPINFO\FOO.LSM Meta aquivo do pacote para o programa FOO
|
|
|
50 |
PROGS\FOO\FOO.EXE O executável do programa
|
|
|
51 |
PROGS\FOO\FOO.TXT Alguma documentação
|
|
|
52 |
PROGS\FOO\FILE.DAT Arquivo de dados usado pelo programa FOO
|
|
|
53 |
|
|
|
54 |
Note o diretório PROGS acima. Essa é a categoria ao qual o pacote pertence.
|
|
|
55 |
O instalador de pacotes pode mudar esse diretório no momento da instalação,
|
|
|
56 |
dependendo das preferências do usuário. Categorias possíveis são listadas
|
|
|
57 |
abaixo:
|
|
|
58 |
|
|
|
59 |
Categoria | Descrição
|
|
|
60 |
DEVEL | Ferramentas de desenvolvimento (a maioria compiladores)
|
|
|
61 |
DRIVERS | Drivers de dispositivo
|
|
|
62 |
GAMES | Jogos
|
|
|
63 |
PROGS | Programas do usuário, ferramentas...
|
|
|
64 |
|
|
|
65 |
Note: Diretórios "DOC", "NLS", "BIN" e "HELP" são reservados estritamente aos
|
|
|
66 |
pacotes CORE.
|
|
|
67 |
|
|
|
68 |
|
|
|
69 |
%hArquivos de metadados LSM
|
|
|
70 |
|
|
|
71 |
Cada pacote DEVE conter um arquivo LSM em seu diretório "APPINFO". Esse arquivo
|
|
|
72 |
LSM é um arquivo de texto que contém informação básica sobre o pacote. Seu
|
|
|
73 |
formato é muito simples, deve conter pelo menos duas linhas:
|
|
|
74 |
|
|
|
75 |
version: x.y.z
|
|
|
76 |
description: descrição do pacote
|
|
|
77 |
|
|
|
78 |
Quaisquer outras linhas adicionais são ignoradas pelo gernciador de pacotes do
|
|
|
79 |
SvarDOS.
|
|
|
80 |
|
|
|
81 |
|
|
|
82 |
%hVersões dos pacotes
|
|
|
83 |
|
|
|
84 |
A vesão presente no arquivo LSM foi pensada para refletir a versão do software
|
|
|
85 |
empacotado, mas pode acontecer de um pacote precisar ser mudado para corrigir
|
|
|
86 |
um problema estritamente relacionado ao pacote em si (por emeplo, um arquivo de
|
|
|
87 |
documentação esquecido ou uma recompilação do binário usando um melhor jogo de
|
|
|
88 |
opções...). Em tais casos, a versão do software não muda, mas a versão do pacote
|
|
|
89 |
em sí precisa mudar, assim os usuários saberão que alguma coisa mudou. É aí onde
|
|
|
90 |
as "Revisões do SvarDOS" entram. Um string de versão é basicamente o formato
|
|
|
91 |
abaixo:
|
|
|
92 |
|
|
|
93 |
UPSTREAM_VER[+SVARREV]
|
|
|
94 |
|
|
|
95 |
UPSTREAM_VER é o exato string de versão informado pelo software. Ele pode ser
|
|
|
96 |
qualquer coisa. Essa versão original (upstream) pode ser opcionalmente seguida
|
|
|
97 |
por um sinal de mais "+" e a revisão do SvarDOS. No evento da versão upstream já
|
|
|
98 |
conter um sinal de mais, a versão da revisão do SvarDOS é delimitada com um til
|
|
|
99 |
"~".
|
|
|
100 |
|
|
|
101 |
A revisão do SvarDOS começa com 0 e incrementa por 1 cada vez que a dada revisão
|
|
|
102 |
upstream é reempacotada. A revisão SvarDOS reinicia sempre que a versão upstream
|
|
|
103 |
mudar. A revisão SvarDOS com 0 é sempre oculta.
|
|
|
104 |
|
|
|
105 |
Exemplos:
|
|
|
106 |
|
|
|
107 |
FDISK 1.54 <- versão empacotada originalmente
|
|
|
108 |
FDISK 1.54+1 <- o pacote mudou, mas não a versão upstream
|
|
|
109 |
FDISK 1.55 <- a versão upstream incrementou, a rev do SvarDOS reinicia
|
|
|
110 |
FDISK 1.55+1 <- nova versão do pacote, mas ainda contém FDISK 1.55
|
|
|
111 |
FDISK 1.55+2 <- outra nova versão do pacote, etc
|
|
|
112 |
|
|
|
113 |
O string de versão inteiro de um pacote nunca deve exceder 16 caracteres.
|
|
|
114 |
|
|
|
115 |
|
|
|
116 |
%hFontes de software
|
|
|
117 |
|
|
|
118 |
Quando um software empacotado tiver arquivos de código fonte disponíveis, é
|
|
|
119 |
recomendado também arquivá-los. Nesse efeito, ponha os fontes num arquivo ZIP
|
|
|
120 |
que tenha o mesmo nome do pacote, mas com uma extensão *.ZIP (em oposição a
|
|
|
121 |
extensão *.SVP própria do pacote). O resultado é que o software empacotado
|
|
|
122 |
seria distribuído com dois arquivos. Exemplo para o FDISK:
|
|
|
123 |
|
|
|
124 |
FDISK.SVP <- binários (arquivo ZIP seguindo a estrutura SVP)
|
|
|
125 |
FDISK.ZIP <- fontes (arquivo ZIP não estruturado, livre)
|
|
|
126 |
|
|
|
127 |
O arquivo ZIP deve obviamente conter o código fonte que pertence exatamente a
|
|
|
128 |
mesma versão presente no pacote SVP.
|