guix-patches
[Top][All Lists]
Advanced

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

[bug#48463] gnu: Add j.


From: elaexuotee
Subject: [bug#48463] gnu: Add j.
Date: Mon, 17 Jan 2022 00:19:18 +0900
User-agent: mblaze/1.1

> > 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?

Attachment: txtxLkV4H2_ZA.txt
Description: Text Data

Attachment: 0002-gnu-Add-j.patch
Description: Text Data


reply via email to

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