Thanks !
On 15/10/13 22:32, Benjamin Drung wrote:
> On Fr, 2013-10-04 at 13:40 +0200, Dominik George wrote:
>> Vincent Lefevre schrieb:
>>> Then, do you mean that VCS hashes are sortable?
>>
>> Of course not. One would have to do something like 0~MMDDnn
>> +git in that rare case.
>>
>> My
On Fr, 2013-10-04 at 13:40 +0200, Dominik George wrote:
> Vincent Lefevre schrieb:
> >Then, do you mean that VCS hashes are sortable?
>
> Of course not. One would have to do something like 0~MMDDnn
> +git in that rare case.
>
> My argument for keeping the VCS hash is to ease identifying
On Fri, Oct 04, 2013 at 01:31:35PM +0200, Vincent Lefevre wrote:
> On 2013-10-02 17:50:40 +0200, Dominik George wrote:
> > That said, what's the point in NOT being verbose?
>
> Version strings need to be displayed, and if they take too much space,
> they may be truncated (e.g. in aptitude).
They
Hello,
On 04/10/13 13:50, Vincent Lefevre wrote:
> On 2013-10-04 13:40:29 +0200, Dominik George wrote:
>> My argument for keeping the VCS hash is to ease identifying the code
>> in the package.
>
> Does it need to be in the version string?
> Why not somewhere else?
>
> The goal of the Version fi
On 2013-10-04 13:40:29 +0200, Dominik George wrote:
> My argument for keeping the VCS hash is to ease identifying the code
> in the package.
Does it need to be in the version string?
Why not somewhere else?
The goal of the Version field in Debian packages is to identify
and sort several versions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Vincent Lefevre schrieb:
>Then, do you mean that VCS hashes are sortable?
Of course not. One would have to do something like 0~MMDDnn+git in that
rare case.
My argument for keeping the VCS hash is to ease identifying the code in the
pac
On 2013-10-02 17:50:40 +0200, Dominik George wrote:
> I established an advantage for the user using my proposal - go get
> me a disadvantage for the packager.
As a user, I dislike long version strings.
> That said, what's the point in NOT being verbose?
Version strings need to be displayed, and
On 2013-10-02 16:51:09 +0200, Dominik George wrote:
> Dominique Dumont schrieb:
> >well, you proposed a version like 'hg'. if upstream switches to
> >git, you can't use a version like 'git' because it sorts before
> >hg. I grant you that is easy to work around.
>
> If you deem it unlikely
Hello All,
I did not expected to initial such a thread: thanks a lot for all the messages
On 02/10/13 20:24, David Prévot wrote:
> Hi,
>
>> Wookey (2013-10-02):
>
>>> It would be good if this 0~ trick
>>> was mentioned there too
>
> Already in the New Maintainers' Guide:
>
> http://www.debia
Jerome BENOIT writes:
> I am packaging a versionless library software maintained via a
> mercurial repository. Is there any custom for this case ?
I have had a surprising rate of success simply asking upstream to make
versioned release tarballs, or at least VCS tags for release versions.
--
\
Hi,
> Wookey (2013-10-02):
>> It would be good if this 0~ trick
>> was mentioned there too
Already in the New Maintainers' Guide:
http://www.debian.org/doc/manuals/maint-guide/first#namever
Regards
David, kinda ashamed to add a message to that longish nitpicking thread
signature.asc
Des
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
>A packager is not required to serve users with such specific needs.
Hmm, I last saw that attitude when being explained "the Arch way".
I established an advantage for the user using my proposal - go get me a
disadvantage for the packager.
That sa
Quoting Dominik George (2013-10-02 16:39:09)
> Wookey schrieb:
>>+++ Dominik George [2013-10-02 16:23 +0200]:
>>>
0~MMDD
should be fine.
>>>
>>> It isn't, it is not a unique identifier for the one "release" you
>>> are packaging.
>>
>> No, but it can be a sufficient identifier s
On Wednesday 02 October 2013 17:31:02 Andrew Shadura wrote:
> > dpkg --compare-versions 1.hg2012 '<=' 1.git2013 || echo 'false'
>
> Weren't we talking about 0~20131002.hg2efc4fcd vs 0~20131002.git67ed491a?
Sorry, I confused between Jerome original mail and Dominik's proposal.
Dominik's idea rai
Hi,
On 2 October 2013 17:27, Dominique Dumont wrote:
>> If you deem it unlikely that two commits are made in the same day (which
>> happens all the time), how likely is it that upstream switches VCSs and
>> does an important commit on the same day?
> that's not the issue. Try that:
> dpkg --com
On Wednesday 02 October 2013 16:51:09 Dominik George wrote:
> >well, you proposed a version like 'hg'. if upstream switches to
> >git, you
> >can't use a version like 'git' because it sorts before hg. I grant
> >you
> >that is easy to work around.
>
> If you deem it unlikely that two commi
Wookey (2013-10-02):
> The 'use an ISO date as version' idea comes from advice in the
> developer packaging docs somewhere. It would be good if this 0~ trick
> was mentioned there too so one could decide whether to use it or not
> at the time of initial packaging.
http://www.debian.org/doc/debian
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dominique Dumont schrieb:
>On Wednesday 02 October 2013 16:05:18 Dominik George wrote:
>> >You should use a version derived from the date only. This way, you
>> >won't be in
>> >trouble if upstream switches to git.
>>
>> I absolutely do not see wh
Wookey wrote:
>+++ Dominik George [2013-10-02 15:49 +0200]:
>> Jerome BENOIT schrieb:
>> >Hello,
>> >
>> >I am packaging a versionless library software maintained via a
>> >mercurial repository.
>> >Is there any custom for this case ?
>
>> I tend to use:
>>
>> 0~MMDD+hgXX
>>
>> It sorts
On Wednesday 02 October 2013 16:05:18 Dominik George wrote:
> >You should use a version derived from the date only. This way, you
> >won't be in
> >trouble if upstream switches to git.
>
> I absolutely do not see why this should be an issue.
well, you proposed a version like 'hg'. if upstream
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Wookey schrieb:
>+++ Dominik George [2013-10-02 16:23 +0200]:
>>
>> >0~MMDD
>> >
>> >should be fine.
>>
>> It isn't, it is not a unique identifier for the one "release" you are
>packaging.
>
>No, but it can be a sufficient identifier so long a
+++ Dominik George [2013-10-02 16:23 +0200]:
>
> >0~MMDD
> >
> >should be fine.
>
> It isn't, it is not a unique identifier for the one "release" you are
> packaging.
No, but it can be a sufficient identifier so long as you don't make more
than one release a day.
Which exact tag/branch/has
+++ Dominik George [2013-10-02 15:49 +0200]:
> Jerome BENOIT schrieb:
> >Hello,
> >
> >I am packaging a versionless library software maintained via a
> >mercurial repository.
> >Is there any custom for this case ?
> I tend to use:
>
> 0~MMDD+hgXX
>
> It sorts just below anything upstrea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
>0~MMDD
>
>should be fine.
It isn't, it is not a unique identifier for the one "release" you are packaging.
- -nik
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid
iQFNBAEBCgA3BQJSTCxtMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYX
Hello,
On 02/10/13 16:05, Dominik George wrote:
> Hi,
>
>> What does 'XX' stand for ?
>
> The short commit hash, as proposed in your initial mail.
In my first email, what you read as a commit hash was meant to be the date.
To summarise:
0~MMDD
should be fine.
Thanks,
Jerome
>
>> Y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
>What does 'XX' stand for ?
The short commit hash, as proposed in your initial mail.
>You should use a version derived from the date only. This way, you
>won't be in
>trouble if upstream switches to git.
I absolutely do not see why this s
Hi Nik,
thanks for your quick reply.
On 02/10/13 15:49, Dominik George wrote:
>
>
> Jerome BENOIT schrieb:
>> Hello,
>
>> I am packaging a versionless library software maintained via a
>> mercurial repository.
>> Is there any custom for this case ?
>> If not, can we use the version format 'hg
On Wednesday 02 October 2013 15:21:48 Jerome BENOIT wrote:
> I am packaging a versionless library software maintained via a mercurial
> repository. Is there any custom for this case ?
> If not, can we use the version format 'hgMMDD' ?
As a user, I don't care about upstream repo.
You should u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Jerome BENOIT schrieb:
>Hello,
>
>I am packaging a versionless library software maintained via a
>mercurial repository.
>Is there any custom for this case ?
>If not, can we use the version format 'hgMMDD' ?
>
>
>Best regards,
>Jerome
I tend t
Hello,
I am packaging a versionless library software maintained via a mercurial
repository.
Is there any custom for this case ?
If not, can we use the version format 'hgMMDD' ?
Best regards,
Jerome
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsu
30 matches
Mail list logo