Re: [MirageOS-devel] Signature mismatch in tcpip 2.2.3

[Thomas Leonard <talex5@xxxxxxxxx>]

On 21 April 2015 at 21:37, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
>
>
> Le mardi, 21 avril 2015 Ã 22:24, Anil Madhavapeddy a Ãcrit :
>
>> How is the version inferred with? Without it:
>>
>> opam pin foo git://github.com/mirage/foo (http://github.com/mirage/foo)
>>
>> ...will have the version of the latest release, I believe.
> Yes, actually I was writing:
>> I'm not sure opam is at fault or can do anything here.
> Mmmh actually that's only if you are assuming that a pin implies bleeding 
> edge. The system I have with topkg makes pin on my packages accurately 
> reports version numbers up to commit by inferring them from the VCS tags for 
> any checkout, e.g. this can be seen in `ocamlfind list`. However it will 
> indeed advertise itself as bleeding edge as far as *opam* is concerned.
>
> So you are right, it seems we are missing a mecanism in the pin procedure to 
> be able to communicate with which version number we would like the pin to 
> advertise itself. I don't think it's a good idea to do this through the 
> `version` field of the repo's opam file; that's too error prone, sync issues, 
> etc. It is the VCS which has that information.

Here's what we do in 0install:

1. The repository contains a version number like "1.2-post" in the
metadata file (the "feed", which corresponds to the "opam" file).

2. At release time, the release tool[1] guesses the next version
number from this (it would guess "1.3" in this case). It prompts the
user to confirm or enter a different number (e.g. "1.2.1").

3. It then commits the metadata file with the chosen version (1.3) and
tags that commit as the release archive.

4. It them commits another change setting the version in the metadata
to 1.3-post.

This way, the versions are always consistent. You can git clone any
revision and it will have the right version. It generally works well.

The only problem I've had is with branches. e.g. if my master branch
has version "1.2-post" and I make a "1.2.1" release from a separate
"fixes" branch then 0install will think that the new 1.2.1 release is
newer than the 1.2-post version on master, and will prefer that as the
bleeding edge. In this (unusual) case you need to manually update the
version in master (to 1.2.1-post or 1.3-pre or somesuch).

It might be worth printing a warning whenever the solver picks a
version that isn't the pinned one.


[1] http://0install.net/0release.html

-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel