oh i just saw this
On 10/4/25 11:45 AM, Wilhelm Spiegl via Freedos-devel wrote:
as you now have (at the moment not working) nls files (short / long
options), can you combine them anyhow?
and, please leave the license out of nls, as it will not be translated
at all.
when this is done, I will try to add more translations.
combining.... i dont know due to the fact of the short hand version wait
a moment.... i have an idea!
dont touch that specific thing yet. ill work on that soon! <3
Installation of very big files works again. I tested a file bigger
than 40 mb, virus database.
NICE! :D
ps, your websites are missing the comparison charts as they are at
ibiblio. this is very helpful as you can see all programs on one side
without clicking through all the sections.
ok ill add that!
Thx
Fritz / Willi
--
Gesendet mit der mail.com <http://mail.com> Mail App
Am 04.10.25, 13:47 schrieb Jerome Shidel via Freedos-devel
<[email protected] <http://lists.sourceforge.net>>:
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.
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]
<http://lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
