i added my notes in here! :D lets talk about this in meetup! :D
On 10/4/25 6:46 AM, Jerome Shidel via Freedos-user wrote:
Hi,
On Oct 3, 2025, at 8:21 PM, victoria crenshaw via Freedos-devel
<[email protected]> wrote:
this version has a new feature! Reinstall and short hand of the
commands! and added / support so u can use fdnpkg16 /in fdnpkg
and an actual bug fix with the watt32 version! :D
16 bit integer overflow so i made it 32 bit long! :D (the variable
not the program)
please get it from
https://4ch.su/freedos/repos/1.4/html/en/net/fdnpkg16/20251003.9/index.html
FYI, on a repository managed by FDRepo that has multiple versions of a
package, the different versions of a package have the modified-date in
the URL.
For example, you currently have two versions of FDNPKG16 available:
0.99.8c++ (2025-10-03.08) and 0.99.81 (2025-10-03.9)
The browsable web pages for those versions have “permanent” URLS of:
https://4ch.su/freedos/repos/latest/html/en/net/fdnpkg16/20251003.8/index.html
https://4ch.su/freedos/repos/latest/html/en/net/fdnpkg16/20251003.9/index.html
This makes it easy to link to a specific version of a package.
However sometimes, it is nice be able to say “get the latest version
of XYZ” instead of a specific version.
This can be done by simply removing the modified-date information from
the URL.
For example, to get the “latest version of FDNPKG” visit:
https://4ch.su/freedos/repos/latest/html/en/net/fdnpkg16/index.html
:-)
<3
i added a contact me thing in the license command or li :D or even /li!
or u can just email me here
if u got suggestions/questions/needing help/ or just wanna chat i am
here for u guys! <3
jerome i have an idea for fdrepo! contact me dude!
it is about index.gz to make index16.gz and that new version have the
modification date on it! :D
While that would provide a more reliable way to determine if there is
an update available, there are other possibilities.
yes!
First, there are a few other things to consider…
* DOS networking is tends to be slower overall.
* While I have not had the opportunity to test FDNPKG16 yet, I know
FDNPKG’s download speed is much slower than programs like CURL.
* Configuring FDNPKG with all the groups for a repository can be
tedious.
* If a group is added to a repository, the user must update their
config file to access it.
* When simply updating your packages, it needs to fetch various
index files which consist mostly of plain text descriptions.
* Plus there are a couple other more minor things.
While FDRepo needs to maintain backward compatibility with FDNPKG,
that does not mean a more efficient system could be put into place
that FDNPKG16 could use.
thats ok! :D thats why i said the index16.gz! we keep the old index.gz
going! :D
While most are aware that the root of a repository (like latest or
1.4) contains sub-directories for each group (like base and games),
there are a couple non-group sub-directories as well. For example,
there is an html directory. This is where 99.99% of the HTML for the
web browsable pages exists. The exceptions are simple landing pages
for the repositories. But, all the group, package, comparison and
other pages for the various languages live under that html
sub-directory. Also, there is an images sub-directory. That is where
all the screen-shots for the package html pages is stored. All that is
to say, there can be other non-group sub-directories in the base of a
repository that serve specific purposes.
yes!
It may be better to provide such a special directory to improve the
overall experience of using a package download and updater like
FDNPKG. There could be a “packages” sub-directory which could provide
several things.
First, it could have a very simple “updated” file. That contains the
date and time anything has updated or added in that repository. If
this timestamp has not changed since the last time the updater checked
for updates, then there is no need to precede any further. This would
help alleviate any issues with the local package information cache
being out of date.
Second, it could contain a “updates.lst" file. It would be formatted
as either TAB or COMMA separated fields. This file could contain only
4 small pieces of information: Package ID,Group Name,Modified Date
and CRC32. The updater program could fetch this file. It would provide
all the information required to determine if an updated version is
present and where to locate it in the repository. There is no need to
provide descriptive text about the package in this file making it
smaller than downloading a bunch of individual listing files from the
different package groups.
Third, having that smaller list of all packages+groups would eliminate
the need to configure each group separately in the updaters
configuration file. It could simple be pointed at the repository and
the updater could handle the rest. This would also make it very easy
to add multiple online repositories which would be in order importance.
However, there is a choice the updater would need to make when dealing
with multiple repositories. It could be configured to only fetch
updated packages from the first (higher priority) repository that
contains the package. Or, to retrieve it from whatever repository
contains the latest version. I lean towards the first option. It would
mean if you have the official repository on IBIBLIO configured, it
would always (and only) fetch updates to standard packages from that
server. Packages that do not exist on IBIBLIO would then get updated
from another server. If you disabled IBIBLIO in your configuration (or
remove it), then the next highest priority server you have configured
would provide the updates instead. On the other hand, if it is simply
permitted to fetch updated packages from any configured server, when
there are problems communicating with a server like IBIBLIO, it could
simply fall back on a lower priority server. I think such behavior
should be user configurable. Possibly, even provide a command line
option to perform a "one-off” fallback on different server when such
communication issues arise.
i like this idea! :D
In the future, other things could be provided. Display a list of
Groups available with Descriptions.. Things to improve searching.
Stuff to determine if other versions are available. Ability to get
full LSM data regarding a package or version. Support to be able to
list the file contents of a package. And possible other benefits as well.
All of which could be great for a new package manager. Also, it does
not break compatibility with existing ones. Best of all, it really is
not more complicated to add than a separate modified-date based index
file to the different groups.
YES!!!!!!!!!!!!!!! :DDDDDDDDD <3
:-)
_______________________________________________
Freedos-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-user
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
