Acompanhar os programas

Question

Quando eu instalo um programa simples, ele geralmente usa make && make install e nem sempre tem um destino desinstalação .

Se eu quiser atualizar um programa, é um protocolo padrão presumir que ele seja reescrito perfeitamente sobre o antigo programa?

Como acompanho esses programas? fazer a maioria das pessoas apenas 'disparar e esquecer' e se nenhum desinstalar destino é dado eu tenho que excluir manualmente tudo?

    

Answer 1

Instale cada programa em uma árvore de diretório dedicada e use o Stow ou XStow para fazer com que todos os programas apareçam em uma hierarquia comum. O Stow cria links simbólicos do diretório específico do programa para uma árvore comum.

Mais detalhadamente, escolha um diretório de nível superior, por exemplo, /usr/local/stow . Instale cada programa em /usr/local/stow/PROGRAM_NAME . Por exemplo, organize seus executáveis para serem instalados em /usr/local/stow/PROGRAM_NAME/bin , suas páginas man em /usr/local/stow/man/man1 e assim por diante. Se o programa usar o autoconf, execute ./configure --prefix /usr/local/stow/PROGRAM_NAME . Depois de executar make install , execute stow :

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

E agora você terá links simbólicos como estes:

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

Você pode facilmente acompanhar quais programas você instalou listando o conteúdo do diretório stow e sempre sabe a que programa um arquivo pertence, porque é um link simbólico para um local no diretório desse programa. Desinstale um programa executando stow -D PROGRAM_NAME e excluindo o diretório do programa. Você pode tornar um programa temporariamente indisponível executando stow -D PROGRAM_NAME (execute stow PROGRAM_NAME para torná-lo disponível novamente).

Se você quiser alternar rapidamente entre diferentes versões do mesmo programa, use /usr/local/stow/PROGRAM_NAME-VERSION como o diretório do programa. Para atualizar da versão 3 para a versão 4, instale a versão 4 e execute stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4 .

As versões mais antigas do Stow não vão muito além do básico que descrevi nesta resposta. Versões mais recentes, assim como o XStow (que não foi mantido ultimamente), possuem recursos mais avançados, como a capacidade de ignorar certos arquivos, lidar melhor com links simbólicos existentes fora do diretório stow (como man -> share/man ), lidar com alguns conflitos automaticamente (quando dois programas fornecem o mesmo arquivo), etc.

Se você não quiser ou não quiser usar o acesso root, poderá escolher um diretório em seu diretório pessoal, por exemplo, %código%. Nesse caso, adicione ~/software/stow ao seu ~/software/bin . Se PATH não encontrar automaticamente as páginas man, adicione man ao seu ~/software/man . Adicione MANPATH ao seu ~/software/info , INFOPATH ao seu ~/software/lib/python e assim por diante, conforme aplicável.

    

Answer 2

Você pode usar o checkinstall para criar um pacote (pacotes compatíveis com RPM, Deb ou Slackware Dessa forma, você pode usar o gerenciador de pacotes distros para adicionar / remover o aplicativo (mas não atualizar)

Você usa checkinstall no lugar do comando make install (usando o parâmetro -D para Deb; -R é RPM e -S é o Slackware):

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

O checkinstall irá construir e instalar o pacote por padrão, ou você pode fazer com que ele apenas construa o pacote sem instalar.

o checkinstall está disponível na maioria dos repositórios distros.

    

Answer 3

Na maior parte, essa foi a razão por trás dos pacotes, portas e outros tipos de gerenciadores para evitar que esse tipo de coisa acontecesse.

Eu diria que a exclusão manual é a única maneira de uma instalação manual, a menos que outra pessoa tenha uma resposta melhor para esse ponto que eu possa não estar ciente.

    

Answer 4

Mais uma alternativa é a partir das dicas Linux From Scratch :

Mais controle e gerenciamento de pacotes usando os usuários de pacotes

3 Package Users
3.1 Introduction

The basic idea of this scheme is easily explained. Every package belongs to a certain "package user". When you install a package, you build and install the package as this package user, causing all files that are installed to be owned by the package user. As a consequence all the usual package management tasks can be comfortably achieved through the use of standard command line utilities. A simple ls -l <file> will tell you, for instance, what package <file> belongs to and a find -user ... command allows you to perform an operation on all the files belonging to a certain package, e.g. delete them to uninstall the package.

But package management is not all that package users are good for. Because package users do not have root-rights, the installation of a package is limited in what it can do. One thing that a package user is not allowed to do, for example, is to overwrite files from a different package user. Clashes between different packages that want to install a binary, library or header file of the same name are more common than you might think. With package users you never run the risk of package B's installation destroying files from package A silently without you noticing. Every attempt of doing this during package B's installation will cause a "Permission denied" or "Operation not permitted" error so that you have the chance of taking appropriate steps. Another thing that package users are not allowed to do is install setuid root binaries. The decision to make a binary setuid root is also something that a prudent admin does not want to leave up to the creator of a software package.

Usually package user accounts have no valid password so that only root can su to a package user, which ensures that package users do not open an additional way into the system and undermine security. But you may set passwords anyway to allow a co-admin who you want to be able to install and maintain certain software packages to do so without having access to the actual root account. This co-admin could for instance install, delete, change additional libraries which might be necessary for his workgroup. He would be unable, though, to remove or modify libraries which don't belong to him/her, such as libc.

Após essa primeira sugestão grosseira, encontrei uma variante evoluída:

crablfs - Sistema de gerenciamento de pacotes baseado em usuário

Este crablfs é o mais recente exemplo de gerenciamento de pacotes usando uids e gids únicos para gerenciamento de pacotes, mas no sourceforge está evoluindo novamente em ulfs:

uLFS: o seu Linux gerenciável e reutilizável a partir do zero

Para usuários causais de pacotes instalados, acho que a solução LFS de "pacotes de usuários" é leve, menos invasiva e elegante. Em suma, você instala pacotes em /usr/local ou /home/user/local e rastreia arquivos usando uids e gids exclusivos para cada pacote, mas coloca todos os arquivos nos locais tradicionais, diretórios comuns /usr/local/bin , /usr/local/lib como em todos os principais Linux distribuições ... oclusão de arquivo e arquivo indesejado sobrescrevendo ou excluindo é evitado por um truque de Linux puro explicado por Matthias S. Benkmann em more_control_and_pkg_man.txt que precisa apenas de manipulação de permissão normal de arquivos e diretórios, por exemplo a permissão de diretórios para evitar indesejados arquivo sobrescreve:

3.3 Groups

Every package user belongs to at least 2 groups. One of these groups is the "install" group, which all package users (and only package users) belong to. All directories that packages are allowed to install stuff in belong to the install group. This includes directories such as /bin and /usr/bin but excludes directories like /root or /. The directories owned by the install group are always group-writable. This would be enough for the package management aspects, but without further preparation this would not give added security or control because every package could replace the files from a different package (the change would be visible in the output from ls -l, though). For this reason all install directories get the sticky attribute. This allows users to create new files and delete or modify their own files in the directory, but files from other users can not be modified or removed. In the rest of this hint, whenever the term "install directory" is used, it refers to a directory that belongs to group install, is group-writable and sticky. IOW, to turn <dir> into an install directory you would do

chgrp install && chmod g+w,o+t

Para mim, parece uma solução simples e inteligente! Eu usei este esquema na minha compilação do LFS e é uma solução de trabalho ...

    

Answer 5

1. Você pode criar um RPM vazio como lembrete.
2. Você pode investigar o envolvimento do software em um RPM.
3. Você pode deixar uma cópia dos arquivos tar da instalação em /usr/src/non-rpms para lembrá-lo (é o que eu costumo fazer).