Claudio Freire (klaussfreire@gmail.com) wrote:
On Tue, Sep 10, 2013 at 4:13 PM, Adam Spiers <aspiers@suse.com> wrote:
Claudio Freire (klaussfreire@gmail.com) wrote:
On Tue, Sep 10, 2013 at 3:44 PM, Adam Spiers <aspiers@suse.com> wrote:
Claudio Freire (klaussfreire@gmail.com) wrote:
On Tue, Sep 10, 2013 at 3:24 PM, Jan Engelhardt <jengelh@inai.de> wrote:
On Tuesday 2013-09-10 20:20, Claudio Freire wrote: > >Since you have the hash, you don't even need more than day precision
Since you have the hash, you don't need *anything else* per se except so as to please the package manager.
So, if it's there to please a human, then it's all the more important to have it human-readable right?
It's not there to please a human. Please read the rest of the thread.
Unbelievable as it may be, I read the whole thread.
It's not unbelievable. But you said "if it's there to please a human" when I've stated several times that it's there to make libzypp-based upgrades work, so it was a reasonable assumption that you hadn't read it.
Well, it's a conditional. Someone said it was for humans. So I reply
"IF it's there to please a human, THEN X"
Right, and the presence of the conditional showed me that this still needed clarifying ;-)
Sorry, I'm perhaps a bit too "technical" in my arguments on the grounds of my dad being a lawyer. I got used to formal argumentative language.
No apology needed, I have some education in predicate calculus (a long time ago) and my mind works in a similar way :-)
The point is sortability, and ISO fulfills it. There's an ISO format without separators too, btw.
ISO adds human readability to sortability.
The only possible ambiguities ISO adds, are timezone-related. But unless you expect to be releasing several times a day, day precision should be enough, and you thus avoid timezones.
I didn't say I was against switching to a ISO format; in fact, I agree with you and would definitely prefer it. However other people are already objecting to the length of a version string which includes the epoch time and an abbreviated hash, so I suspect that increasing the length further by switching from epoch time to ISO would cause more objections to including this in the guidelines.
It may be. But it would at least be for a good reason.
Totally agreed. The only anti-length argument which carries any conviction to me is the Joliet one.
That said, there's nothing in principle stopping you from using "%ci" in tar_scm's versionformat parameter instead of "%ct". I say "in principle" because it doesn't *quite* work yet: whilst hyphens are already automatically stripped:
https://github.com/openSUSE/obs-service-tar_scm/blob/master/tar_scm#L410
it seems to barf on the colons. Pull requests welcome ;-)
It seems the simple change at line 410 from
|sed 's@-@@g'
to
|sed -r 's@[-:]@@g'
would do the trick
Not sure it'd have any unforeseeable side effects, not knowing that code in particular. But it seems safe.
Agreed, I think that would be fine. Please don't forget to add a test to the test suite before you submit the pull request ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org