Re: dpkg and depends on version again
brian white writes ("Re: dpkg and depends on version again "):
> > This will be implemented in dpkg 1.0.9 (along with the retirement of
> > the Revision field as discussed and announced a few months ago).
> I think I must have missed that. Could you post it again?
Here is one of the relevant messages, from last July.
------- start of forwarded message (RFC 934 encapsulation) -------
To: Debian developers list <firstname.lastname@example.org>
Subject: Re: Version vs. Package_Revision harmful ?
Just over half a week ago I wrote the message below.
The response to my suggestion was thin but generally positive.
I therefore propose to modify dpkg in the near future so that:
* Only the Version field is considered for version number checking.
* If a non-empty Package_Revision or Revision field is encountered
its contents are appended to the Version (with a hyphen in-between)
and the Revision is discarded.
The visible effect of this will be that things like dpkg --status
and dselect's package control file display will no longer show
Revision fields, but will instead show the revision folded into the
To avoid confusion the revision number (the component after the
hyphen) will not be allowed to contain any hyphens; this isn't a
problem, I think, because none currently do. Hyphens in the upstream
version number will not be a problem.
When the new C dpkg is generally released package maintainers can
change their packages so that they no longer have Package_Revision
fields. They can do this at the same time as switching to virtual
package names for Depends; they can choose whether or not to wait
until they have to rebuild for ELF anyway.
Maintainers of packages which do not have a Package_Revision field
should not add any even if they have to release an upgrade - they
should add the revision number onto the end of the Version.
Some time after the ELF rollout I'll remove the special support for
Does anyone object to the above ?
> Quite a while ago we split the package revision out of the version
> number and made it a separate field in the control file.
> In certain contexts, though, it is still in one piece - in the
> uploaded filenames, release announcements, general mailing list
> messages, and in the bug reports. This is because it's sometimes
> convenient to quote a version number that way, without having to bring
> whole the whole field name baggage into it.
> The distinction has caused a nonzero amount of confusion, and is
> irrelevant for the packaging software. IMO it should continue to be
> How do people feel about the following ?
> *NB* This is NOT a request for any action by package maintainers,
> other than to comment if you feel you have something to say.
> I propose that the Package_Revision field be phased out. It would be
> removed from all documentation (except perhaps noted as a deprecated
> feature), and the Guidelines would be changed back to specify
> constructing a single version number in the `<version>-<revison>'
> format (this is important for consistency).
> dpkg, dpkg-deb and dselect can all be made to understand the new
> format and transparently convert it to the new. dpkg-deb could be
> made to issue a warning when building a package containing
> Package_Revision, and could re-write the package control file if it
> found one.
> The process would be transparent to users apart from the reduction in
> The changes will be non-harmful to developers, and will only require
> the modification of control file fields together with everything else
> (see my message about changes).
------- end -------