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 .

[mocore]

wrt previous mentioned *known format* and checking format correctness

i just discovered "GNU recutils – human readable, plain text databases "

GNU Recutils is a set of tools and libraries to access human-editable, plain text databases called recfiles. The data is stored as a sequence of records, each record containing an arbitrary number of named fields.

https://www.gnu.org/software/recutils/manual/recutils.html#Invoking-recins

Code: [Select]

echo "" | recins -f Name -v "Mr Foo" -f Email -v foo@bar.baz


Name: Mr Foo
Email: foo@bar.baz

[patrikg]

Sorry to inject another format like json, all this format wars.
But see more of Linux tools like ip can output to json.

[CNK]

@mocore: Yes I was looking at using GNU Recutils for some tasks related to managing extension info files and it matches the info format very closely, so you could probably generate a Recutils database with just a little more than a "cat *.info". The main extra thing is you need to add a '+' at the start of new lines in field values (see here).

As usual I haven't gotten around to any of it myself and there are more useful projects for me to (not) get around to first...

patrikg: JSON? Much worse, I like the readability of the current Recutils-style.

[mocore]

*fanfare*
ftr ...

 title : "Script for retrieving selected fields from .tcz.info files" @ https://forum.tinycorelinux.net/index.php/topic,27456.msg176787.html
 script : ParseInfoFile.sh
 url : https://forum.tinycorelinux.net/index.php?action=dlattach;topic=27456.0;attach=6971
 thaughts : outsidethebox

This script was inspired by a thread that talked about handling .info files.
What the planned endgame there is, I still don't know.

I did find these statements a bit disturbing:

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

and

... Yes, adopting a standard would increase machine readability. ...

It sounds like the idea is to make life easier for computers and more difficult
for people creating the .info file.

note : @rich thanks for the script/comments 

 observation : correlational between disturbing / misapprehensions and posts / scripts in Programming & Scripting - Unofficial
 conclusion : more misapprehensions more scripts

[mocore]

@CNK

 it appears each item in the Free Software Directory (FSD)
has a .rec file

 and the fsd includes a total of "(17041)"  items !
 idk how many are packaged in each core version/arch repo(s) 

so (ftr) it appears that
 any one considering tcz-packaging a package included in FSD could "import" existing fields from the projects ./FSD (.rec) file
 perhaps with  ParseInfoFile.sh  ....


... which might be construed as
 - making the lives of  "people who (attempt to) use computers to produce .tcz extensions" easier

eg : the recutils FSD.rec

https://git.savannah.gnu.org/cgit/recutils.git/tree/FSD

# -*- mode: rec -*-
#
# Information for the Free Software Directory maintained
# by the Free Software Foundation at http://www.fsf.org/directory

%rec: FSD_Entry http://www.jemarch.net/downloads/FSD.rec

Title: GNU Recutils
Description:
+ GNU Recutils is a set of tools and libraries to access human-editable
+ text-based databases called recfiles.  The GNU recutils suite
+ comprises a Texinfo manual describing the rec format, a C library
+ (librec) providing a rich set of functions to access rec files, a set
+ of C utilities (recinf, recsel, recins, recset and recfix) that can be
+ used in shell scripts, and an Emacs mode (rec-mode).
GNU: yes
Homepage: http://www.gnu.org/software/recutils
PublicVCSCheckout: git clone git://git.sv.gnu.org/recutils.git
License: GPLv3PLUS
License: GFDLv21PLUS
Maintainer: Jose E. Marchesi <jemarch@gnu.org>
Version: 1.7
MaturityLevel: Production
DevelList: http://www.gnu.org/mailman/listinfo/bug-recutils
HelpList: http://www.gnu.org/mailman/listinfo/help-recutils
InterfaceStyle: CommandLine
InterfaceStyle: Console

# End of FSD

https://git.savannah.gnu.org/cgit/recutils.git/tree/etc/FSD.rec

# FSD.rec - Record descriptor for FSD entries
#
# This file contains the record descriptor for entries in the Free
# Software Directory.
#
# The canonical location of this file is
# http://www.jemarch.net/downloads/FSD.rec

# Copyright (C) 2010, 2020, 2022 Jose E. Marchesi

# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

%rec: FSD_Entry
%mandatory: Title
%type: Title line
%type: GNU bool
%type: MaturityLevel enum
+ Undefined Planning PreAlpha Alpha Beta
+ Production Mature Orphaned
%type: License enum
+ GPLv2 GPLv2PLUS GPLv3 GPLv3PLUS
+ GFDLv21PLUS
%type: InterfaceStyle enum
+ CommandLine Console Daemon XWindow Web Email

# End of FSD.rec

[NewUser]

Isn't the info file for the person installing the extension?

[Rich]

Hi NewUser
Yes, it's for the user installing the extension.