[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?
txtxLkV4H2_ZA.txt
Description: Text Data
0002-gnu-Add-j.patch
Description: Text Data
- [bug#48463] gnu: Add j., (continued)
- [bug#48463] gnu: Add j., Maxime Devos, 2022/01/12
- [bug#48463] gnu: Add j., Maxime Devos, 2022/01/12
- [bug#48463] gnu: Add j., elaexuotee, 2022/01/12
- [bug#48463] gnu: Add j., Liliana Marie Prikler, 2022/01/12
- [bug#48463] gnu: Add j., elaexuotee, 2022/01/13
- [bug#48463] gnu: Add j., Liliana Marie Prikler, 2022/01/13
- [bug#48463] gnu: Add j., elaexuotee, 2022/01/15
- [bug#48463] gnu: Add j., Liliana Marie Prikler, 2022/01/15
- [bug#48463] gnu: Add j., elaexuotee, 2022/01/16
- [bug#48463] gnu: Add j., Liliana Marie Prikler, 2022/01/16
- [bug#48463] gnu: Add j.,
elaexuotee <=
- [bug#48463] gnu: Add j., Liliana Marie Prikler, 2022/01/16
- [bug#48463] gnu: Add j., elaexuotee, 2022/01/16
- [bug#48463] gnu: Add j., Liliana Marie Prikler, 2022/01/17
- [bug#48463] gnu: Add j., elaexuotee, 2022/01/17
- [bug#48463] gnu: Add j., Liliana Marie Prikler, 2022/01/18
- [bug#48463] gnu: Add j., elaexuotee, 2022/01/18
- [bug#48463] gnu: Add j., Liliana Marie Prikler, 2022/01/18