Una cadena de versió no demostra una funció del connector VPN

Tres preguntes separen un argument de versió d'una investigació de funcionalitat: quin component ha de proporcionar l'opció, quina versió d'aquest component hi ha realment instal·lada i què en diu el seu registre de canvis. El número d'un connector per si sol no respon cap d'elles. La drecera temptadora, comparar una versió escurçada amb el mínim d'un tutorial, falla perquè les cadenes de versió de les distribucions no són decimals. Decidiu què esteu comparant abans de comparar-ho.

L'opció pot viure a NetworkManager, al seu connector VPN, al motor subjacent o en un frontal d'escriptori separat. Són quatre projectes amb quatre històries de versions.

Quatre components, quatre històries de versions

L'editor que veieu sol ser un connector, i el connector crida un motor com el binari OpenVPN o una implementació de WireGuard. El mateix NetworkManager proporciona el model de connexió, i un frontal d'escriptori pot afegir-hi camps propis. Una funció pot aparèixer en qualsevol d'ells, i actualitzar-ne un no actualitza els altres. Un motor més nou no és prova que l'editor instal·lat pugui importar una opció que el motor admet.

Comenceu pel símptoma: falta el camp al diàleg, és absent després de la importació o hi és però s'ignora? Aquestes observacions assenyalen components diferents i necessiten proves diferents.

Analitzeu la versió abans de comparar-la

La política de paquets de Debian defineix el format com a epoch, versió upstream i revisió d'empaquetatge. Es compara primer l'epoch, després la part upstream i després la revisió, amb les regles d'ordenació del gestor de paquets, no amb aritmètica decimal ni amb una ordenació alfabètica simple. La titlla s'ordena abans que tot, inclòs el final d'aquella part, i així és com un candidat de versió precedeix la versió final. Llegir les parts per separat és el que fa significativa la comparació.

No inventeu una regla de conversió per a algun altre esquema en què 0.8.999 sembli proper a 0.9. La proximitat de xifres no és prova sobre el contingut.

Pregunteu què hi ha instal·lat i què hi hauria d'haver-hi

apt-cache policy informa de la versió instal·lada, del candidat i del repositori d'on ve cadascun, per a cada paquet que nomeu. Llegiu-ho tant per al motor com per al connector, i anoteu cadenes completes en lloc de formes escurçades. Les metadades locals poden ser obsoletes, i una versió candidata no demostra que un procés en execució hagi carregat aquesta compilació. Si un servei no s'ha reiniciat des de l'actualització, el fitxer del disc i el comportament que observeu poden discrepar.

Després llegiu el registre de canvis corresponent. Una revisió d'empaquetatge pot portar pedaços sense adoptar un número upstream nou, i és exactament el cas en què la versió sembla inalterada i el comportament difereix.

Demostreu l'opció al component propietari

Per a un problema d'importació, inspeccioneu els camps admesos del connector instal·lat i el resultat desat, no només el diàleg. Una etiqueta, un camp de dades natiu i un argument del motor poden ser tres representacions d'un mateix paràmetre, i l'èxit en importar un fitxer no diu res sobre si cada directriu ha sobreviscut. Nomeneu la funció amb precisió: per exemple, acceptar aquesta directriu conservant-ne el significat per a l'autenticació.

Si la compilació admesa per a aquesta versió no té la integració, trieu un camí d'actualització aprovat o un altre client. Barrejar el repositori d'una altra versió, o aplicar un pedaç de codi arxivat per apujar un número visible, canvia un argument de versió per un sistema no admès.

Un informe útil anomena la distribució, les versions completes dels paquets, el propietari de la connexió activa, l'opció necessària i el comportament desat observat. Aquesta és una pregunta reproduïble.