> On Mar 27, 2025, at 10:01 AM, Paul Dufresne via Freedos-devel
> <freedos-devel@lists.sourceforge.net> 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
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
