bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19219: Package names with digits following dashes


From: Mathieu Lirzin
Subject: bug#19219: Package names with digits following dashes
Date: Tue, 22 Dec 2015 22:23:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Mathieu Lirzin <address@hidden> skribis:
>
>> The test case contains the example "guile-2.0.6.65-134c9" which
>> invalidates my proposal.  Here is another idea which identifies the
>> version part by the presence of dots.  WDYT?
>
> Sometimes the version part does not contain dots, as in “diffoscope-34”.
> Here’s the complete list of dot-less versions:

Oops, I have totally overlooked that.  I have blindly followed the
examples in the test case.  Sorry about that.

> scheme@(guile-user)> ,use(gnu packages)
> scheme@(guile-user)> (fold-packages (lambda (p r)
>                                     (if (string-index (package-version p) #\.)
>                                         r
>                                         (cons (package-full-name p) r)))
>                                   '())
> $38 = ("xterm-320" "unclutter-8" "tidy-20091223" "perl-uri-find-20140709" 
> "libx264-20150706-2245" "vapoursynth-28" "texlive-texmf-2015" 
> "texlive-bin-2015" "texlive-2015" "scmutils-20140302" 
> "perl-regexp-common-2013031301" "parallel-20151122" "diffoscope-34" 
> "mg-20050429" "ngircd-22" "bootstrap-tarballs-0" "static-binaries-tarball-0" 
> "usbutils-006" "kmod-17" "less-481" "libjpeg-9a" "libjpeg-8d" "hugs-Sep2006" 
> "ghc-bifunctors-5" "ghc-nats-1" "brdf-explorer-17" "libgudev-230" 
> "psutils-17" "gcal-4" "libspiro-20071029" "fontforge-20120731-b" 
> "font-gnu-freefont-ttf-20100919" "pcb-20140316" "paredit-24" 
> "sfarkxtc-b5e0a2ba39" "lz4-131" "ld-wrapper-0" "glibc-bootstrap-0" 
> "gcc-bootstrap-0" "binutils-bootstrap-0" "bootstrap-binaries-0" "bless-1p02" 
> "tzdata-2015c" "freepats-20060219" "acpica-20150410")
>
> Would they still be suitably parsed?

Nope, we are screwed! :) There are too many combinaisons.

> I liked that the initial algorithm was trivial, as in Nix:
>
[...]
> DrvName::DrvName(const string & s) : hits(0)
> {
>     name = fullName = s;
>     for (unsigned int i = 0; i < s.size(); ++i) {
>         /* !!! isalpha/isdigit are affected by the locale. */
>         if (s[i] == '-' && i + 1 < s.size() && !isalpha(s[i + 1])) {
>             name = string(s, 0, i);
>             version = string(s, i + 1);
>             break;
>         }
>     }
> }

Baahh.

In fact I think that having the same character for separating words and
version is a design flaw.  This brings non desirable limitations when
choosing a package name (as shown in this bug report) and/or requires a
complex parsing algorithm.  We could use a reserved character instead
(just like we do for multiple outputs).  My proposition would be to have
':' for versions and '/' for outputs, like this:

  guile:1.8/doc
  xterm-256-color:320
  emacs:24.5/out

WDYT?

> Another option would be to return a list of possible name version pairs,
> and to change the UI to try them one after another?  The downside would
> be that it moves complexity to the UI.  Hmm…

This sounds like possible non-determinism, so it feels ugly.  ;)

--
Mathieu Lirzin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]