Re: [Freedos-devel] LSM (Linux Software Map) entries: Entered-date fields

[<je...@sh...>]

> On Mar 27, 2025, at 10:01 AM, Paul Dufresne via Freedos-devel <fre...@li...> wrote:
> 
> I think there is so much confusion about the Entered-date fiels, that maybe we should switch on using version 4.
> 
> 
> "The 1999-12-22 version (version 4) is only a minor change from version 3.
>   - First, version 4 entries begin with a line containing "Begin4" rather
>     than "Begin3".
>   - The other difference is that dates are now in the format specified in
>     ISO 8601 <http://www.cl.cam.ac.uk/~mgk25/iso-time.html <http://www.cl.cam.ac.uk/~mgk25/iso-time.html>>."
> 
> Because in version 4, the Entered date is defined as:
> The 1999-12-22 version (version 4) is only a minor change from version 3.
>   - First, version 4 entries begin with a line containing "Begin4" rather
>     than "Begin3".
>   - The other difference is that dates are now in the format specified in
>     ISO 8601 <http://www.cl.cam.ac.uk/~mgk25/iso-time.html <http://www.cl.cam.ac.uk/~mgk25/iso-time.html>>.
> See https://lsm.qqx.org/LSM.README <https://lsm.qqx.org/LSM.README>
> 
> But we use version 3, where it should be:
> 
> Entered-date:   Date in format ddMMMyy of when the LSM entry was last
>                 modified, where dd is 2-digit day of month, MMM is
>                 ALL-CAPITALIZED first 3 English month letters, and yy
>                 is last two digits of the year in the Gregorian
>                 calendar.  Note that you should fill in both Version
>                 and Entered-date.
> according to: https://www.ibiblio.org/pub/Linux/docs/LSM/LSM.README <https://www.ibiblio.org/pub/Linux/docs/LSM/LSM.README>
> 
> Also, I come on the subject because for Bolitare, we now have:
> Begin3
> Title:          Bolitaire
> Version:        0.62b
> Entered-date:   2015-12-04
> Description:    A Freecell card game
> Author:         Yogesh
> Copying-policy: GNU General Public License, Version 2
> Summary:        A Freecell card game for DOS.
> Modified-date:  2025-03-23.2
> End
> 
> Where a Modified-date was added, but Entered is supposed to be the date of last modification (both in
> version 3 and 4)
> 

When going through all of the various packages available to FreeDOS, the Entered-Date field was a complete and total mess.

Sometimes the value was the “very first time the package was created”, 
Sometimes “when that version was created”, 
Sometimes “when anything in the package was updated”,
Sometimes “only when the binaries were updated"
Sometimes the build time which was neglected for a few versions,
and other values which possible meant something to someone.

On top of that, the information was represented in whatever format the individual felt like using. For example:

23mar15, 23MAR15, 23-MAR-15, 23-March-2015, 3/23/15, 03/23/2015, 15-03-23, and on and on.

This haphazard gathering of various formats is a pain to process through simple automation and makes operations like sorting difficult. 
But more important, when viewing lists of packages on the download /update repositories it looked atrocious and unprofessional.

Most of this likely occurred from the lack of any automation. It would require whoever included the update to always examine the
field for accuracy and format consistency every single time a package changed. 

So a long while back, I went through and standardized that field in all packages on the YYYY-MM-DD format. I also have the Repository 
Management Utility (aka FDREPO) verify the correct format is used. If it is not, it will reject the package and not add it to the download/update 
repo until it has been corrected.  But, that information is still rather inconsistent and useless. 

Hence, the Modified-date field was added and its format is enforced by the utilities. Eventually when the field is present (always on the download
Repository), tools like FDIMPLES will use that field instead of relying on parsing the Version or trying to use Entered-date. 

When editing an LSM, the Modified-date field is not something to be concerned about adjusting. Originally, it was only added the the LSM
by the FDREPO when it was not present and the package was added to a download repo (usually my unofficial repository). I would then
download the updated version and upload that to the official repository. This would keep the packages identical. 

The recent update to FDVCS includes support to update that field using a slightly different method. It will scan the entire package finding 
the latest updated file. It will then use that timestamp to update that field and apply the same timestamp to the LSM file. Assuming 
the file timestamps are correct, this make sure the modified-date field is accurate to the last change of the package contents. 

Since whenever a package at GitLab is updated, I will update my local copy, apply the timestamp preservation routine in FDVCS and 
some other housekeepings stuff. Then, I will push the updated information back to GitLab. GitLab does not preserve timestamps on its
own. So depending on wether or not the individual who initially pushed the changes used FDVCS to update the timestamp, the record
times can be off a few days. 

As a bonus, I can update the Modified-date field in every package in just a few minutes using the new FDVCS tool. Under a local directory
which contains all of the projects, I can simply run:

fdvcs.sh -ens -fe -f -mod -c “udpdate metadata modified-date field”

Breaking that command down… 

-ens		(Error No Stop) Do not stop processing additional projects with a “ForEach” if an errors occurs. Just move on to the next project.
-fe		For each project, perform the following built-in commands of the utility
-f		(Fetch) If there are any updates to the project on the server, pull them. 
		If needed, update the timestamp database and restore the timestamp of files.
-mod 	Find the latest updated file. If needed, Update or Add the modified-date field and LSM timestamp.
-c		If needed, Create a new INDEX.md page with updated metadata.
		If needed, update the timestamp database file. 
		If needed, commit and push the changes back to GitLab.

At some point in the near future, I am likely to have the Commit/Push option automatically perform -mod and -lfn. 

While the information in the Entered-date is anyones guess to what it represents, the Modified-date field is kept reasonably
accurate through various automated utilities. I am currently working on the next version of FDREPO and it will contain the 
same logic for setting that field if for some reason it is not present. Same goes for the next edition of the RBE. Probably
for the current RBE version after 1.4 is released when it is switched over to the new version of FDVCS.

Among several other things, I recently used FDVCS to update/add that field and perform some other cleanup across
all of the projects. That includes the removal of all current CI/CD runners. When the new version of FDREPO is done,
I will likely create a new CI/CD for the projects. One that only performs verification of the project directory structure and
metadata files. Since packages can be created locally with FDVCS or downloaded from the IBIBLIO Repository, it will no 
longer create “packages” on GitLab itself. 

:-)

Jerome