On 02/02/2018 09:14 AM, James Clarke wrote:
On 2 Feb 2018, at 16:07, S├ębastien Villemot <sebast...@debian.org> wrote:
On Fri, Feb 02, 2018 at 04:23:37PM +0100, Christophe Trophime wrote:
Hi,
I would like to update a package feelpp from its latest release 0.103.2 to a 
more recent development version.
I've tried to define the newest version as: 0.103.3+gitREVNUMBER with REVNUMBER 
the id of the git commit

The trouble is that when trying to update locally my package which are stored 
in a local repo
apt still wants to install 0.103.2 version instead of the newest 
0.103.3+gitREVNUMBER

What do I miss to get the dev version to be installed?

Since 0.103.3+gitREVNUMBER > 0.103.2 (can be easily checked with "dpkg 
--compare-versions"),
the problem does not come from versioning, but more likely from apt pinning.

Whilst that version number does compare fine, it's likely to be problematic for
any future development versions, since 0.103.3+git0123456 sorts before
0.103.3+gitfedcba9, even though 0123456 may be a newer commit. To avoid this,
it's common to include the date of the commit in the version number, often as
0.103.3+YYYYMMDD.gitREVNUMBER.

Another option is to use "git describe", which can be made to give you:

${MOST_RECENT_TAG}-${NUMBER_OF_COMMITS_SINCE_TAG}-g${SHA}

In your example it might be "0.103.2-45-g0123456", which has the properties you want from a version number (after you translate the "-" characters to ".".

You can use --match to select what tags to pay attention to, for example "release/*".


--
Sebastian Kuzminsky

Reply via email to