En versjonsstreng beviser ikke en funksjon i en VPN-plugin
Et pakkenummer er ikke en funksjonsliste. Analyser epoch, upstream og revisjon, sjekk hva som er installert, og bevis deretter alternativet der det bor.
Tre spørsmål skiller et versjonsargument fra en funksjonsundersøkelse: hvilken komponent som skal levere alternativet, hvilken versjon av den komponenten som faktisk er installert, og hva endringsloggen sier om det. Nummeret til en plugin alene svarer på ingen av dem. Den fristende snarveien, å sammenligne en forkortet versjon med et minimum fra en veiledning, mislykkes fordi distribusjoners versjonsstrenger ikke er desimaltall. Bestem hva du sammenligner før du sammenligner det.
Alternativet kan bo i NetworkManager, i VPN-pluginen deres, i den underliggende motoren eller i en separat skrivebordsfrontend. Det er fire prosjekter med fire utgivelseshistorier.
Fire komponenter, fire utgivelseshistorier
Editoren du ser er vanligvis en plugin, og pluginen kaller en motor som OpenVPN-binæren eller en WireGuard-implementasjon. NetworkManager selv leverer tilkoblingsmodellen, og en skrivebordsfrontend kan legge til sine egne felt oppå. En funksjon kan dukke opp i hvilken som helst av dem, og oppgradering av én oppgraderer ikke de andre. En nyere motor er ikke bevis for at den installerte editoren kan importere et alternativ som motoren støtter.
Begynn med symptomet: mangler feltet i dialogen, er det fraværende etter import, eller er det til stede men ignorert? Disse observasjonene peker på forskjellige komponenter og krever forskjellige bevis.
Analyser versjonen før du sammenligner den
Debians pakkepolicy definerer formatet som epoch, upstream-versjon og pakkerevisjon. Først sammenlignes epoch, deretter upstream-delen, deretter revisjonen, etter pakkebehandlerens egne sorteringsregler og ikke desimalaritmetikk eller enkel alfabetisk sortering. En tilde sorteres før alt, også før slutten av den delen, og det er slik en utgivelseskandidat går foran den endelige utgivelsen. Det er den separate lesingen av delene som gjør en sammenligning meningsfull.
Ikke finn opp en konverteringsregel for en eller annen annen ordning der 0.8.999 ser nær 0.9 ut. Talls nærhet er ikke bevis om innholdet.
Spør hva som er installert og hva som ville være det
apt-cache policy rapporterer den installerte versjonen, kandidaten og lageret hver av dem kommer fra, for hver pakke du navngir. Les den for både motoren og pluginen, og noter fullstendige strenger i stedet for forkortede former. Lokale metadata kan være utdaterte, og en kandidatversjon beviser ikke at en kjørende prosess har lastet den byggingen. Hvis en tjeneste ikke er startet på nytt siden oppgraderingen, kan filen på disken og atferden du observerer være uenige.
Les deretter den samsvarende endringsloggen. En pakkerevisjon kan bære patcher uten å ta i bruk et nytt upstream-nummer, og det er nettopp tilfellet der versjonen ser uendret ut og atferden er annerledes.
Bevis alternativet i komponenten som eier det
For et importproblem, undersøk de støttede feltene til den installerte pluginen og det lagrede resultatet i stedet for bare dialogen. En etikett, et opprinnelig datafelt og et motorargument kan være tre representasjoner av én innstilling, og vellykket import av en fil sier ingenting om hvorvidt hver direktiv overlevde. Navngi funksjonen presist: for eksempel å godta denne direktivet mens betydningen for autentisering bevares.
Hvis den støttede byggingen for den utgivelsen mangler integrasjonen, velg en godkjent oppdateringsvei eller en annen klient. Å blande lageret til en annen utgivelse, eller å bruke en arkivert kildeplaster for å heve et synlig nummer, bytter et versjonsargument mot et system som ikke støttes.
En nyttig rapport navngir distribusjonen, de fullstendige pakkeversjonene, eieren av den aktive tilkoblingen, det nødvendige alternativet og den observerte lagrede atferden. Det er et reproduserbart spørsmål.