Re: Can we find a better idiom for unversioned packages?

[Liliana Marie Prikler <leo.prikler@student.tugraz.at>]

Am Mittwoch, den 01.09.2021, 19:48 +0000 schrieb Jonathan McHugh:
> September 1, 2021 8:35 PM, "Liliana Marie Prikler" <
> leo.prikler@student.tugraz.at> wrote
> 
> > Making our rando commit git versions look like such other distro
> > versions does come at a disadvantage though, particularly when we
> > look
> > at it through the lense of someone not used to Guix' versioning
> > scheme.
> > Instead of telling us "yeah, this is the Nth time we picked a rando
> > commit since the last release and this time it's de4db3ef", users
> > coming from such distros would assume "oh well, this is still good
> > ol'
> > 1.0 with some more patches applied". So while the commit itself
> > does
> > not give us any particularly useful information (unless you're that
> > person who uses this part of the version string to look the commit
> > up
> > on hubbucket), especially not when thinking in the context of
> > versioning scheme, it does provide the existential information of
> > "hold
> > on, this is not a release commit, it's something else" and might
> > thus
> > direct users to be a little more attentive when they'd otherwise go
> > "yep, upstream considers this solid and Guix considers it even more
> > solid, so it's the solidest". Note, that this can be overcome both
> > by
> > teaching/learning about it and by using a special sigil as
> > mentioned
> > above.
> 
> Perhaps a function revealing metadata based upon the version string
> would allow more people get an overview without visiting hubbucket^1?
I don't think that information is actually encoded anywhere nor
immediately obvious unless you're vaguely familiar with said software,
but it's still important e.g. if reading the documentation.  Does this
feature mentioned in the frobnicatorinator 1.44 docs apply to 1.36 or
not?  Do the examples from some book written in the early 70s work if I
compile them with GCC 12?  And so on and so forth.

> Would that be any weirder and awkward for workflows than the command
> `guix download'?
> => 
> https://guix.gnu.org/manual/en/html_node/Invoking-guix-download.html
Imo the only thing awkard about guix download is that it only handles
tarballs when a large chunk of packages use some sort of version
control.  We might want to look over that at some point and specify
revisions/commits to download on the command line.

> Even better, highlighting the part of the string and launching an
> appropriate context in Emacs-Hyperbole

> > My personal answer to this might be a disappointing one, as in that
> > case I believe we wouldn't even need procedures like git-version to
> > form them, but could instead use <upstream-version>-<guix-revision> 
> > as a mere convention like many more popular distros already do. If
> > the dash is overused for that, we could also use a different
> > symbol, though perhaps there's not that many on a typical US
> > keyboard to reserve one as a revision delimiter.
> 
> # Apologies for being off topic
> The inclusion of that character '£' on keyboards bothers me - Ive
> never seen anybody use it (though maybe I have some fuzzy memory with
> regards to the Commodore 64).
Pretty sure people in the UK used it for their currency even pre-
Brexit, but if you're used to $ for everything it might be
understandable why you're confused.

> If it unfortunately is on an international band of keyboard classes
> consider it as a delimiter. Otherwise Im ripping out that button and
> never interfacing the number 3 again.
Are you okay?

> ^1 Is that pronounced bouquet? 
> => https://keepingupappearances.fandom.com/wiki/Hyacinth_Bucket
I regret clicking on that.  While bucket and bouquet are etymologically
related, at least according to Wiktionary, I'd assume the generally
accepted pronunciation would be /hʌbˈbʌkɪt/, though there may be local
variations.