Ein versjonsstreng bevisar ikkje ein funksjon i ein VPN-plugin

Tre spørsmål skil eit versjonsargument frå ei funksjonsgransking: kva komponent som skal levera alternativet, kva versjon av den komponenten som faktisk er installert, og kva endringsloggen seier om det. Nummeret til ein plugin åleine svarar på ingen av dei. Den freistande snarvvegen, å samanlikna ein forkorta versjon med eit minimum frå ei rettleiing, mislukkast fordi versjonsstrenge til distribusjonar ikkje er desimaltal. Bestem kva du samanliknar før du samanliknar det.

Alternativet kan bu i NetworkManager, i VPN-pluginen deira, i den underliggjande motoren eller i ein separat skrivebordsfrontend. Det er fire prosjekt med fire utgjevingshistorier.

Fire komponentar, fire utgjevingshistorier

Editoren du ser er vanlegvis ein plugin, og pluginen kallar ein motor som OpenVPN-binæren eller ein WireGuard-implementasjon. NetworkManager sjølv leverer tilkoplingsmodellen, og ein skrivebordsfrontend kan leggja til sine eigne felt oppå. Ein funksjon kan dukka opp i kva som helst av dei, og oppgradering av éin oppgraderer ikkje dei andre. Ein nyare motor er ikkje bevis for at den installerte editoren kan importera eit alternativ som motoren støttar.

Byrja med symptomet: manglar feltet i dialogen, er det fråverande etter import, eller er det til stades men ignorert? Desse observasjonane peikar på ulike komponentar og krev ulike bevis.

Analyser versjonen før du samanliknar han

Pakketpolitikken til Debian definerer formatet som epoch, upstream-versjon og pakkerevisjon. Først blir epoch samanlikna, deretter upstream-delen, deretter revisjonen, etter pakkehandsamaren sine eigne sorteringsreglar og ikkje desimalaritmetikk eller enkel alfabetisk sortering. Ein tilde sorterer før alt, også før slutten av den delen, og slik går ein utgjevingskandidat føre den endelege utgjevinga. Det er den separate lesinga av delane som gjer ei samanlikning meiningsfull.

Ikkje finn opp ein konverteringsregel for ein eller annan annan ordning der 0.8.999 ser nær 0.9 ut. Nærleiken til tal er ikkje bevis om innhaldet.

Spør kva som er installert og kva som ville vera det

apt-cache policy rapporterer den installerte versjonen, kandidaten og lageret kvar av dei kjem frå, for kvar pakke du namngjev. Les han for både motoren og pluginen, og noter fullstendige strengar i staden for forkorta former. Lokale metadata kan vera utdaterte, og ein kandidatversjon bevisar ikkje at ein køyrande prosess har lasta den bygginga. Viss ein teneste ikkje er starta på nytt sidan oppgraderinga, kan fila på disken og åtferda du observerer vera usamde.

Les deretter den samsvarande endringsloggen. Ein pakkerevisjon kan bera patchar utan å ta i bruk eit nytt upstream-nummer, og det er nettopp tilfellet der versjonen ser uendra ut og åtferda er annleis.

Bevis alternativet i komponenten som eig det

For eit importproblem, gransk dei støtta felta til den installerte pluginen og det lagra resultatet i staden for berre dialogen. Ei etikett, eit opphavleg datafelt og eit motorargument kan vera tre representasjonar av éi innstilling, og vellukka import av ei fil seier ingenting om kvar direktiv overlevde. Namngje funksjonen presist: til dømes å godta denne direktivet mens tydinga for autentisering blir bevart.

Viss den støtta bygginga for den utgjevinga manglar integrasjonen, vel ein godkjend oppdateringsveg eller ein annan klient. Å blanda lageret til ei anna utgjeving, eller å bruka ein arkivert kjeldeplaster for å heva eit synleg nummer, byter eit versjonsargument mot eit system som ikkje er støtta.

Ein nyttig rapport namngjev distribusjonen, dei fullstendige pakkeversjonane, eigaren av den aktive tilkoplinga, det nødvendige alternativet og den observerte lagra åtferda. Det er eit reproduserbart spørsmål.