Suggestion to embrace the yaml format for .info files

[CardealRusso]

Hello. I would like to make a suggestion to start using the yaml format in .info. I personally have no experience with yaml, but I've found that it's the most similar to the current non-standard format and the change would be insignificant.

I'll use http://tinycorelinux.net/14.x/x86_64/tcz/cairo-dev.tcz.info as an example.

The only change would be the description and changelog, in case there are multiple lines.
There are two options:
1. Use a multi-line variable.
It would look like this:

Code: [Select]

Change-log:|
            2012/11/09 first version
            2012/11/16 updated 1.10.2 -> 1.12.8
            2013/11/05 updated 1.12.8 -> 1.12.16
Or array:

Code: [Select]

Change-log:
            - 2012/11/09 first version
            - 2012/11/16 updated 1.10.2 -> 1.12.8
            - 2013/11/05 updated 1.12.8 -> 1.12.16
Apparently using spaces or tabs makes no difference, as long as only one is used in a multiline/array variable (using tabs and spaces in the same variable would probably not be correct).

https://codebeautify.org/yaml-parser-online

[mocore]

the (current) tcz.info format to meh appears more or less
like the http header format  *

- https://www.rfc-editor.org/rfc/rfc9110.html#name-message-context

with the exception of the multilline change-log field you mention

suggestion to start using the yaml format in .info.
I personally have no experience with yaml, but I've found that it's the most similar to the current non-standard format

and the change would be insignificant.

>the change would be insignificant.
for who ? would it be so !?? i wander

if this is the case what advantage would this bring ?

or rather with what(language) and to what purpose are you trying to parse .info files ?
and
 consider using awk 
i cant read the example info with out thinking up some methods to try and handle the multi-line Change-log field case tbh 

or perhaps for this case its possible * to modify on the fly *
eg  include ` sed -e's/Change-log:/Change-log:|/g ` this pipeline before processing tcz..info field ?


*( http header format ftr is also much like tiddlywiki's .tid files https://tiddlywiki.com/static/TiddlerFiles.html  )

[CardealRusso]

>the change would be insignificant.
for who ? would it be so !?? i wander

Hello. It wouldn't be necessary to adapt all the existing .info files, just the ones that have been updated.

if this is the case what advantage would this bring ?

A standard, without too much effort.

or rather with what(language) and to what purpose are you trying to parse .info files ?
and
 consider using awk 

Actually, I'm not trying to parse the info, at least not now.

or perhaps for this case its possible * to modify on the fly *
eg  include ` sed -e's/Change-log:/Change-log:|/g ` this pipeline before processing tcz..info field ?

I don't think it's that easy.
Your example didn't work, but if it did, it probably wouldn't return the same results in the next .info from a different author.

[mocore]

hi CardealRusso
thanks for your reply / perspective

>Actually, I'm not trying to parse the info, at least not now.
in that case your subconscious  *is* piloting to write one while you are distracted 

>I don't think it's that easy.
agreed
all though ... it appears the problem is less the "current non-standard format" and more "current non-standard format's"

if this is the case ( imho it appears so ) * see also : "repology-updater/issues/784# Tiny core linux  ~  https://forum.tinycorelinux.net/index.php/topic,26273.0.html "

or perhaps *even more* accurately
the problem is
the current info files are intended for human consumption as plain text
not for programmatic / machine readability & processing

the latter obviously implies "trying to parse the info"

 with this in mind
changing "description and changelog, in case there are multiple lines." the format
would (imho) only solve the problem for new/updated info files **
**assuming the *new* format was *somehow(by what process??!!)* enforced

that(imho)  in-effect would add one more *known format* to the potential options ....

which  reminds me of  submit-TCZ  script to help check for problems before sending extensions
 
... some *automated* method to identify the differences in format   of info files currently in the repo (that could then be considered as alternative format  or be corrected / standardized to a common format )
seams more likely to bring machine readability to info fles / the reop
 

[gadget42]

xkcd ftw

https://xkcd.com/927/

[CardealRusso]

the current info files are intended for human consumption as plain text
not for programmatic / machine readability & processing

the latter obviously implies "trying to parse the info"
....
seams more likely to bring machine readability to info fles / the reop

Yes, adopting a standard would increase machine readability.

[CardealRusso]

... it appears the problem is less the "current non-standard format" and more "current non-standard format's"

if this is the case ( imho it appears so ) * see also : "repology-updater/issues/784# Tiny core linux  ~  https://forum.tinycorelinux.net/index.php/topic,26273.0.html "

Sorry, I missed that part.
Indeed.

http://tinycorelinux.net/14.x/x86_64/tcz/alsa-modules-6.1.2-tinycore64.tcz.info

Change-log:     

http://tinycorelinux.net/14.x/x86_64/tcz/bash-completion.tcz.info

Change-log:     -

http://tinycorelinux.net/14.x/x86_64/tcz/adoptopenjdk-12.tcz.info

Change-log:     ----

http://tinycorelinux.net/14.x/x86_64/tcz/88x2bu.tcz.info

Change-log:     ----------

http://tinycorelinux.net/14.x/x86_64/tcz/aalib-dev.tcz.info

Change-log:     first version

http://tinycorelinux.net/14.x/x86_64/tcz/advcomp.tcz.info

Change-log:     2012/12/02 first version

http://tinycorelinux.net/14.x/x86_64/tcz/aterm.tcz.info

Change-log:     first version
                2013/10/20

http://tinycorelinux.net/14.x/x86_64/tcz/brave-browser.tcz.info

Change-log:     2021/03/25 first version
                ...

[mocore]

xkcd ftw

https://xkcd.com/927/

fwiw aka "For What It's Worth (Stop, Hey What's That Sound)"

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

if the use of embrace in  "to embrace the yaml" was not intended as  'Young in cheek'  ?
  it might be considered `culturally insensitive`  to those  affected by proprietary licensing 
... see also https://en.wikipedia.org/wiki/Halloween_documents

that aside ...  its interesting to see the question of machine readability (re)appear again .