On 08/15/2014 01:24 AM, Ulrich wrote: > Yes I think this a good idea. About the PATH: What about creating an external > batchfile like C:\PKGS.BAT, that is automatically called by AUTOEXEC.BAT? > FDNPKG could update the PATH statement according to each package. The > content, for example: > > PATH=%PATH%;C:\FDOS\DRIVERS\CRYNWR > PATH=%PATH%;C:\FDOS\PROGS\DOSZIP > > and so on.
There is one big problem with this approach: we are quite limited in memory under FreeDOS... At some point, the PATH will become too long to fit into the environment (happened to me years ago). This is why I am rather wondering about adding a single directory to the PATH: SET PATH=%PATH%;%FREEDOS%\LINKS And adding there batch files to call programs from within their 'real' directory. For example C:\FDOS\LINKS\DOSZIP.BAT could contain this: @D:\PROGRAMS\DOSZIP\DOSZIP.EXE %1 %2 %3 %4 %5 %6 %7 %8 %9 This is actually what I do (manually, so far) on my own system since years. FDNPKG would only have to take care to compute proper "link" files. > As you see above, I would put DOSZIP in PROGS instead of C:\. What's the use > of these categories, if we do not use them? Looking at the DOSZIP package, it sould have been installed in %FREEDOS%\BIN, not in C:\... It's weird you got it end up in C:\. But in any case, yes, this is not optimal, and it's yet another relict of times when nobody cared about 3rd party apps under FreeDOS, and everything was landing somewhere in %FREEDOS%\. I fixed this package right now (goes into %PROGS% now, as you suggested, this seems to be the most appropriate solution). > No, I think creating another BIN directory like /usr/bin in GNU/Linux, where > we'd put all third-party executables, would complicate things. The next step > would be to put configuration files in /ETC. No I think it would be wise, to > stay with the DOS way and keep each program and its configuration files in > one dedicated directory. Yes, I'm not much into forced "unixification" of FreeDOS, too (although I am a Linux/BSD aficionado). > Shouldn't CTMOUSE just go into C:\FDOS\DRIVERS\CTMOUSE? I think opening > another drivers/programs directory under C:\FDOS\BIN isn't so helpful. Indeed, this sounds quite fine to me. Done. > Thanks. I installed the correct mirror.exe just now. And BTW: Shouldn't > DOSLFN be in the UTIL repository? > I can find it at the FreeDOS homepage under UTIL but not in the repo. Sure, just a matter of someone contributing a proper package for this. > I am not sure about this. AFAIK Jack R. Ellis, the developer of UIDE also > takes care of RDISK and XMGR and I think he puts it in one package. It is > also updated frequently. So maybe the other way round would be a better way > to go: Removing XMGR and RDISK as separate packages and installing just UIDE > with BASE. I noticed, too, that some developers prefer to create a single archive with all their tools inside. It's easier to distribute, I guess, but my feeling is that software should be distributed functionally - ie. I usually looks for "a program that solves my xyz problem", and almost never "a program created by the developer Abc". Same goes for mTCP and WatTCP - I am not sure if distributing it 'all in one' like we do today is a good idea. Having it exploded into multiple packages might be preferable, functionally (ftp, ping, etc). > FDNPKG works fine from C: in VirtualBox. I am really impressed that I can > update my DOS programs now just like I do with apt on my Debian server. Great to hear! > But obviously the all_cd boot configuration didn't work too good with > VirtualBox, so installation is another puzzle to solve. My (not so) hidden agenda when building all_cd was not to create a product by itself. I was only hoping that such quickly hacked CD might act as a catalyst for getting people's attention to what FDNPKG can potentially be useful for, and maybe provide some incentive for someone to build a real FreeDOS installer/distro on top of it. Seems it works so far ;-) The nice thing behind my build system is that it can provide an "always fresh" FreeDOS distro. It's just a matter for FreeDOS packagers to throw newer packages into the ibiblio repo, and the CD can be rebuilt automatically. Mateusz >>> Am 13.08.2014 um 08:48 schrieb Mateusz Viste <mate...@viste.fr>: >>> >>>> On 08/13/2014 12:07 AM, Rugxulo wrote: >>>>> Are you saying this is a bug in FD FDISK or VBox? Because as long as >>>>> it's not FD FDISK getting inherently confused, you could maybe do a >>>>> simple workaround: copy it to and run from RAM disk. Would that avoid >>>>> the issue? Just curious. >>>> >>>> I have no idea, truly. FDISK 1.2.1 works. FDISK 1.3.1 doesn't. But as >>>> you know, this kind of problems is rarely black or white, so >>>> everything's possible. >>>> >>>> I think the best is to downgrade FDISK to v1.2.1 on FDNPKG repos. Will >>>> do this today. The v1.3.1 does print warnings about being "unstable/beta >>>> version" all over the screen, which might indicate it's not totally >>>> finished yet. >>>> >>>> Mateusz >>>> ------------------------------------------------------------------------------ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
