GNU bug report logs - #48463
gnu: Add j.

Previous Next

Package: guix-patches;

Reported by: elaexuotee <at> wilsonb.com

Date: Sun, 16 May 2021 10:54:02 UTC

Severity: normal

Tags: patch

Merged with 43080

Full log


View this message in rfc822 format

From: elaexuotee <at> wilsonb.com
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Maxime Devos <maximedevos <at> telenet.be>, 48463 <at> debbugs.gnu.org
Subject: [bug#48463] gnu: Add j.
Date: Mon, 17 Jan 2022 00:19:18 +0900
[Message part 1 (text/plain, inline)]
> > Interesting idea. How about just always forcing a MINOR part, setting
> > to "0" if upstream doesn't have one?
> That'd declare regular releases as MAJOR.0 in the version field, which
> I'm not sure if we want that.  In the case of random commits I'm less
> reserved, as they don't correspond to releases anyway.

I see your point. In fact, upstream releases start with MINOR part "a" and
"count up" through the letters over the course of a year. It's a pretty simple
scheme. For example, J 901 started at "j901-release-a" and ended at
"j901-release-f".

When I originally wrote this package, I noticed that the release tag for the
first J 902 was "j902-release", and so treaded MINOR as potentially optional.
However, after checking upstream's forums, this looks to just be a git tag
mishap.

How about we just go ahead and treat MINOR as mandatory as well?


> > If you have a better idea, I am all ears.
> You could define that file-union right after ijconsole.  If you want to
> golf even more, you could define ijconsole inside that file-union, i.e.
>   (define jsoftware-aux-files
>     (file-union "jsoftware-aux-files"
>       `(("profile.ijs" ,(search-aux-file ...)
>         ("ijconsole" ,(program-file ...))))
> 
> I'm not quite sure if you want to use jsoftware-aux-files directly as
> input or whether it's wiser to stuff it into another union like 
> (file-union "jsoftware-aux-input" `(("aux" ,jsoftware-aux-files))).
> search-input-file will probably do the right thing regardless.
> The new style should also still work with assoc-ref, it'd just be
> weirder to look at.  Lastly, you could code up a (search-file-input)
> just in case; I'm not sure if we have one already.

The file-union seems like a cludgy workaround to me. What we really want is an
easy, direct way to get handles on the input files. Heck, program-file objects
already have a name property; why can't we use that? Attached patches are a
proof-of-concept.

That said, if this is going to turn into a big rabbit hole, can we just munge
the J package inputs into whatever you think is best?

[0001-packages-Expand-range-of-objects-add-input-label-can.patch (text/x-patch, attachment)]
[0002-gnu-Add-j.patch (text/x-patch, attachment)]

This bug report was last modified 346 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.