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.8/index.html> https://4ch.su/freedos/repos/latest/html/en/net/fdnpkg16/20251003.9/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 <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. 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. 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. 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. 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. :-)
_______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
