Ian Jackson <[email protected]> writes: > Russ Allbery writes:
>> We might want to recommend against the latter approach because it tends >> to cause problems if upstream maintenance changes, but maybe that's >> more of a developers' guide thing? (And I'm not sure it really causes >> that many problems; the package just becomes non-native, which isn't >> that painful as I recall.) > Changing either source formats and/or version numbering to or from > native works fine and doesn't cause any trouble, assuming that the > version numbers are chosen reasonably sensibly. So I don't think it's > a practical problem. > You make very good points above, which lead me to think recommending > against these practices may be controversial. It would be eaiser just > to state the things that are definitely implied. Yeah, I think that's what I'd prefer. My belief from past discussions is that there isn't a project consensus for ruling out the less-used combinations because there are certain circumstances in which they're quite useful, although there are a substantial number of people who don't like those exceptions and would prefer we push people into a narrower range of options. >> Possibly add: >> and non-native source packages can have native versions (but this is >> rare). >> although I'm not sure. > Non-native source packages with native versions cannot function. I'm > pretty sure no-one is doing that. Oh, yes, this is me stumbling over the definitional problem again. Not for this change, but I really wish we had less ambiguous terminology. It is incredibly hard (at least for me) not to mix up the three concepts here: * Non-native maintenance (there is an upstream independent of Debian and the Debian package is a packaging of that upstream). * Non-native package (the packaging splits the upstream source from the Debian packaging and modifications) * Non-native version (the package version has a debian_revision component) I was thinking of native versions with non-native maintenance, and then wrote native versions with non-native packages, which you are of course correct is impossible. Your text is good here. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
