SvarDOS community forum

Many network-capable DOS computers are not safe to connect to Internet (and it generally not really necessary). Is there is a nice way for downloading all packages and setting up a local (LAN) copy of repository, preferrably FTP based? One link to download all up to date packages at once would cover most of the above.

If it is "just" about downloading all packages, then it would be as simple as that: svn co svn://svn.svardos.org/svardos-pkgs This will, however, just give you packages that you will need to somehow copy on your DOS PC and then install/update them using the 'pkg' tool. In other words, it won't usable by pkgnet as it will miss the pkgnet http interface. To set up a functional pkgnet repo you would need a Linux machine with apache2 and php, and mirror the entire svardos repo as follows: svn co svn://svn.svardos.org/svardos then generate an index of packages: cd svardos php buildidx/buildidx.php packages/ and finally, load apache and point its web root to the svardos/website directory Once you have this set up, it is relatively easy to keep your mirror up to date by issuing a "svn up" within the svardos directory + regenerating the repo index with buildidx.php. This is actually what the server at svardos.org does, from within a cron. On top of the above, you will of obviously need to fiddle with your LAN environment so the DOS PC resolves "svardos.org" as pointing to your Linux server. This can be easily achieved with some lightweight DNS server, like dnsmasq. Alternatively you can try adding a static host entry to WATTCP, but I've never tested this so I cannot vouch for it. In theory this might work (replace 192.168.0.5 by the IP address of your Linux server): ECHO 192.168.0.5 svardos.org > C:\SVARDOS\CFG\HOSTS SET HOSTS=C:\SVARDOS\CFG\HOSTS pkgnet checkup Mateusz

Ah, great, I should be able to set it up now. Why many SVP packages are accompanied by zip? Do I need them as well?

Hi, ZIP files are raw sources (it is what is downloaded via pkgnet pullsrc pkgname), while the SVP files are the actual (binary) packages. Mateusz

A method to say "the repository is at E:\REPO" would enable alternative solutions such as etherdfs.

> A method to say "the repository is at E:\REPO" would enable alternative solutions such as etherdfs.

It is not as easy as it might look like. pkgnet is designed to be as lightweight as possible, for this reason all the intelligence is on the server side, who can perform fast processing of packages, do version comparisons, etc. Having all this being done by pkgnet would certainly be possible, but it would likely require a 386+ machine to be usable. This is something I have done in the past (FDNPKG, Svarog386) and I am really not happy about how things turned out: huge, slow, protected-mode blob that requires several megs of memory to do it's job. Another issue is that the repository contains different versions of packages, and for this reason it relies on long filenames. It is no issue for the repos server as it runs on a modern web server, but LFN isn't available under plain true DOS (and even with hacks like DOSLFN or such it is still not available on CDROMs nor network drives). A realistic alternative approach could be to automate the building of a "simplified" repository that could be downloaded for easy offline use. Such repository would contain only binary versions of packages (no sources) and only the latest version for every package, with all filenames stored in 8+3. Then, pkgnet could be asked to do a "checkup" action on such simplified flat repository and print out all packages that are in a version different than the currently installed package, so the user would be able to decide what he wants to upgrade. This is very much doable even on a 8086, but it would require quite some work to implement. This is something I mentioned some time ago on the ticket list: https://github.com/SvarDOS/bugz/issues/17 Mateusz

>for this reason all the intelligence is on the server side, who can perform fast processing of packages, do version comparisons, etc.

I see. Didn't know it had such a design. One way to approach it would be to do the "hard work" on the repository side, yet serve the repository as something static. Maybe sort the versions, save the sorted list and other useful information for the client to have less work to do within a file. And potentially use some arbitrary filename scheme such as directories that contain versions, to work around 8+3 limitation. Ideally, the repository would become some sort of plugin from the tools' perspective, allowing for http, ftp, kermit over serial or over tcp, local filesystem and any other useful methods. Yet I do understand this is a low priority as we have something that works somewhat, whereas there's tools that actually need replacement (such as freedos edit until the recent new editor).

Pre-sorting versions won't work, because the version installed locally can be potentially different than any version present in the repo. The pkgnet tool would have to include a smart (complex, expensive) version-comparison routine. Nothing impossible of course, I've done it in the past, but it's extra work (and processing time). Using directory names for versions also won't work as-is, because there can be only one dot in 8+3. An example of a version string: "1.0.4b+2". This is obviously not a valid 8+3 name, which means that version strings would need to be mangled one way or another to make them fit inside 8+3. Lots of corner cases to cover. The more important question in my opinion is "what need would this solve"? Myself, I see basically two scenarios: 1. a PC with networking 2. a PC without networking The first case is easy - just use the internet repo, it's what it's for. Or, for paranoid people - host a mirror of the repo on premise (as I explained a couple of messages back), on some RPi or something. The one feature that would be nice here is to be able to point pkgnet at an alternative repo server instead of relying on a hardcoded url to svardos.org. Case number 2 is more problematic. Sometimes a non-ethernet PC can still be connected to the network through its RS232 port using SLIRP, or through its parallel port using PLIP, but that's not always possible. In such situation we are left with only the filesystem on a removable medium - like a CDROM, DVD, ZIP drive or floppy (or USB, if the BIOS supports it). And this is the case where I think my idea of a "simplified, binary-only, latest versions only" repo dump would work pretty well. Packages would be guaranteed to have 8+3 names (because no version strings in filenames, since only one version is shipped anyway) and the repo would be relatively compact because it has binaries only, so it would easily hold on a CD (current size would be 315 MiB). Version comparison being simplified to "is the version string the same as my local one" means that it would work 95% of the time, and corner cases are delegated to the human eyes of the operator. The "simplified repo" would have a single index file - basically the list of all packages. Such index file would be about 5 KiB big so it can be easily copied on a floppy. Then pkgnet would be executed against this index file and spit out the list of "package candidates" for upgrade (ie packages locally installed but with a version different than the latest available on the simple repo). Then the operator would know exactly which files he should copy to the machine using floppies, kermit, or whatever else. That being said, I do appreciate the idea of having a full-blown, multi-version repository available locally via kermit over serial. I just don't see any practical need that it would solve and that cannot be solved in a much more straight-forward way. Mateusz