Re: epoch fix?
Matt Zagrabelny wrote :
> is there a consensus or quorum that believes that unnecessary epochs is
> undesirable?
I don't think so. Package maintainers may have different views of the meaning
of "unnecessary" in this context.
> could we add a field to debian/control such as "Supersede-Epoch". After the
> next stable is released with this version of the package, then the maintainer
> could remove
I see no need to get rid of epochs. I think version ordering should be
preserved forever. See also below on what Peter Green wrote.
> the mechanism of "really" a mechanism for working around unnecessary epochs
I'm with Thorsten Glaser on "*much* more ugly" although I would remove a few
instances of "*much*". :-) I do understand however that some people prefer
adding "really" above adding or bumping epoch if it's just a one time fix in
the version ordering. So far I don't see reason to make the "really" approach
a "must" rule in policy or a recommended good practice in devref.
Scott Kitterman wrote :
> The "really" mechanism is useful for derivatives that don't want to get a
> higher epoch than Debian, but in Debian, I totally agree.
I understand that derivatives sometimes don't need to copy the epoch from
Debian. An obvious consequence is that users shouldn't mix packages from
Debian and Ubuntu on one system, which is already a rule of common sense as far
as I know.
Jonathan Nieder wrote :
> Epochs were invented to handle changes to the version numbering *scheme*.
Yes, that corresponds to my understanding. I still think that epochs can also
be used in other cases.
Michael Biebl wrote :
> The usage of really (...) that you don't have to fix all r-deps to include
> the the epoch in the Build-Depends.
Why would adding an epoch cause the need for adding the epoch in the
build-dependent packages ?
Peter Samuelson wrote :
> Lots of tools use them (...) We cannot be sure that they all use dpkg's own
> interfaces to do so (e.g. dpkg --compare-versions, perl -MDpkg::Version).
Those tools should follow dpkg's behavior, in my opinion. If such a tool
doesn't follow dpkg's behavior, then it's a bug in that tool. I agree however
that we shouldn't modify dpkg's behavior too easily, because that could
instantly break those tools if those tools don't use dpkg itself for version
comparisons.
Peter Green wrote :
> Not to mention that just because the debian archive only cares about version
> numbers within the last few releases does not mean other tools may not care
> about maintaining sane ordering over longer periods.
I agree with that. I think version ordering should be preserved forever.
Regards,
Bart Martens
Reply to: