Os programas que usam sua biblioteca devem ser vinculados a libNAME.so
, se quiserem a versão mais recente, com libNAME.so.X
se quiserem a versão mais recente da versão principal X
e com libNAME.so.X.Y
se quiserem uma versão secundária específica.
Se você acabou de fornecer os links extras para libNAME.so
, libNAME.so.X
e libNAME.so.X.Y
a libNAME.so.X.Y.Z
, todos usarão a versão mais recente e você poderá atualizar esses links.
Suponha que a versão que você está instalando apresenta a versão menor, antes disso os links seriam (suponha que Y-1 seja o número antes de Y e z o nível de patch mais recente da série X.Y-1):
libNAME.so -> libNAME.so.X.Y-1.z
libNAME.so.X -> libNAME.so.X.Y-1.z
libNAME.so.X.Y-1 -> libNAME.so.X.Y-1.z
após a atualização ser instalada (Z provavelmente é 0, talvez 1):
libNAME.so -> libNAME.so.X.Y.Z
libNAME.so.X -> libNAME.so.X.Y.Z
libNAME.so.X.Y-1 -> libNAME.so.X.Y-1.z
libNAME.so.X.Y -> libNAME.so.X.Y.Z
qualquer programa que esteja explicitamente ligado para usar o X.Y-1 ainda encontrará o arquivo X.Y-1.z.
Seguindo este esquema, não há necessidade de atualizar nenhum dos links anteriores para além dos indicados e você pode determinar quais deles são se o seu número principal, menor ou de correção muda (1, 2, resp 3 links).
Costumava ser muito mais comum ter versões antigas de bibliotecas no seu sistema com esses links "intermediários". Mas o gerenciamento de pacotes geralmente elimina as versões antigas.¹
¹ Eu sempre gostei desta maneira de fazer as coisas, contando com os links para obter a versão mais recente, se não explicitamente pedindo um mais antigo. Na conferência Microsoft MFC (1994), onde as DLLs foram apresentadas como uma solução para bibliotecas compartilhadas, indiquei ao orador o problema de acessar versões mais antigas sem um esquema já comprovado. A frase "inferno da DLL" ainda tinha que ser inventada nesse ponto.