Hi, > On Feb 15, 2022, at 10:59 PM, Michael Brutman <mbbrut...@brutman.com> wrote: > > I'm working on a new mTCP version, and this thread reminded me to ask about a > problem. > > I update mTCP more often than FreeDOS gets updated; it's under active > development and I need to get fixes out. Where this becomes a problem is > that I often see people using the 2013 version of mTCP because they got it > with FreeDOS and did not know that they could look for updates. And while > that was a solid release, it has been superseded by a release that is almost > 7 years newer. With lots of bug fixes and enhancements too …
At present, the version that will be on FreeDOS 1.3 final dates from 3/7/2020. > > How can I alert FreeDOS users using mTCP that they should check for newer > versions? Would it be possible to add a second README.TXT (or something > similar) in the directory where mTCP gets installed? > > Also, does mTCP get installed in it's own directory or does it share a > directory with other networking utilities? (I'd prefer it to be separate, as > it is a standalone project. That also keeps the README.TXT or other file > conflicts to a minimum.) > Those are all good questions. :-) First, to explain where mTCP gets installed. I should go into at least a little about how packages get installed. Like all programs, mTCP actual installation and removal of the files is handled by FDINST. This is the case for programs installed by the Primary Installer (FDI) or later through the use of FDIMPLES. (This is not the case with the Floppy Edition installer FDI-x86. It uses SLICER. However, it creates the additional files needed to use programs like FDIMPLES, FDINST, etc. after installation). When FDINST installs a package, the directory structure in the zip archive are more or less aliases that then get mapped to actual directories. Unless overridden, the mapping is defined in the %DOSDIR%\BIN\FDNPKG.CFG file. For example if a package contains a path called \PROGS\APP, the \PROGS gets remapped to C:\ and it files in that path get put under C:\APP. Likewise \BIN is mapped to %DOSDIR%\BIN. However, many of these mappings use the same directory as the alias. At present, this is the case for MTCP. The package has it’s executable and document files under \NET\MTCP. So if a user has not modified the mapping config file, they would get installed into C:\NET\MTCP. So, yes.. Additional files can be added without much concern of conflicts. And, yes… it should be in it’s own directory. As for alerting users that there is an update, I couldn’t say. However, there are some things you can consider that could make it a lot easier for end users to have the latest version of you program. Nowadays, there is a simple process in place for the packages that get included with a FreeDOS release or placed on the official online repository. All such packages get staged in their own GitLab repository under the FreeDOS archive group https://gitlab.com/FreeDOS <https://gitlab.com/FreeDOS> . The packages there are fully extracted, with sources, executables, translations and metadata. They kept in a ready to “zip-and-ship” package directory structure for FreeDOS. When the RBE (Release Build Environment) creates the OS release install media (USB sticks, LiveCD, etc), it clones the projects from GitLab that will be included in the release. It performs some analysis and verification on those files then compresses them for inclusion on the media. Those GitLab projects are also the preparation and staging area for the packages that go into the Official FreeDOS Software Repository https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/ <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/> . Network aware package managers like FDNPKG can check the official repository. Then retrieve and update the packages installed on the user’s computer. My recommendation is to request developer access to the package staging project for mTCP at https://gitlab.com/FreeDOS/net/mtcp <https://gitlab.com/FreeDOS/net/mtcp> . By doing so, you could ensure we always have the latest version on any release of FreeDOS. It would also help us keep the version in the Online Repo up to date as well. Then there is also the added benefit of being able to setup alerts for if a user reports an issue. On a side note, the Online repository is not currently up to date with many projects in the GitLab Archive. There have been a bunch of updates to programs. And, just about all the package metadata has been modified numerous times. Instead of constantly updating the ones in the Online Repo, I’ve been putting it off until just before the release of 1.3 Final. At which point, I’ll probable purge the current repo and refresh all the packages with the latest versions from GitLab. > > Regards, > Mike :-) Jerome
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
