Put standard kernel under \svardos\kernel\default and remove SYS

[boeckmann]

I made a package for SYS and updated the EDRDOS package to not include DRSYS anymore. SYS can only be installed if the kernel package gets uninstalled before, because SYS is already there. I recommend

1. to remove SYS from the kernel package
2. include the SYS package as core package
3. move the FreeDOS kernel to SVARDOS\KERNEL\DEFAULT

[boeckmann]

Ok perhaps we simply leave the default kernel under \svardos. The rest I tried to change by myself. @mateuszviste I hope that I did not utterly broke something. Perhaps you have a look...

[mateuszviste]

I reviewed the svn history and it looks very good, thank you! It seems you figured out all the pieces of the puzzle. I even see that the website published a new "bleeding" version right away after your changes and the build succeeded so it seems cool (I will test this bleeding version later today or tomorrow).

As for the kernel, I think it would make sense to keep it in SVARDOS\KERNEL\FREEDOS for consistency/clarity. Esp. since EDR is likely to become the new default soon. In fact, I'd really like to proof test the current "bleeding" version, make it the new stable and then push EDR into bleeding.

[boeckmann]

I ran the build.sh locally (ran very smooth on my Mac) and tested the 1.44 image in 86box before committing the changes. I hope the images for the other sizes work too, but I did not test every single one :)

The kernel is still the dual-file version. I will create packages for two other kernels the next days: ECMs single-file EDR version and the current FreeDOS devel kernel for 8086 + FAT32 compiled with Watcom. I tested the latter today under 86box for IBM XT. Seems to work fine.

[mateuszviste]

https://github.com/SvarDOS/bugz/issues/85 is about a new pkg feature that would make pkg more user-friendly (user won't break a package just by renaming its filename). This feature could also be used to simplify the way kernels are distributed & installed, so switching to a different kernel or a different shell would be a single pkg command (and a reboot, of course). This is, however, the opposite of what is being discussed in this issue. I am on the fence between the two approaches. While the method discussed here is definitely nice for developers and "power-users", the method proposed by https://github.com/SvarDOS/bugz/issues/85 is undoubtedly easier and less risky for any normal user that just wants to give another kernel or shell a test ride.

[boeckmann]

I am not sure what would be better. What should be avoided is that the user gets confused by the package name and the filename that provides the package. For example if 4DOS.SVP provides "CMD", how to uninstall? pkg remove 4DOS or pkg remove CMD? Could be solved by looking at the suffix, so pkg remove 4dos.svp has the same effect as pkg remove cmd.

[boeckmann]

Also, how to determine which kernel is installed if every kernel package is named KERNEL?

[mateuszviste]

What should be avoided is that the user gets confused by the package name and the filename that provides the package. For example if 4DOS.SVP provides "CMD", how to uninstall? pkg remove 4DOS or pkg remove CMD?

That would be "pkg install comm4dos" to install and "pkg remove cmd" to uninstall. And indeed, you are right that it looks somewhat odd. On the other hand, I think these packages (kernel/shell) should never be uninstalled, since that would break the system, so the odd nomenclature is maybe a non-issue for all practical purposes.

Also, how to determine which kernel is installed if every kernel package is named KERNEL?

By looking at the package's documentation in %DOSDIR%\DOC\KERNEL I suppose. Another improvement could be to include the description of packages in the output of "pkg listlocal" (albeit that would make this listing noticeably slower on 4 MHz workstations)

[mateuszviste]

There is one important limitation that I realize only now: if "COMM4DOS.SVP" effectively installs a package "COMMAND", then how PKGNET would know that it has to look up "COMM4DOS" for online updates? I can't think of any simple solution to that (ie a solution that would not have to involve yet another layer of metadata), and such limitation is a huge issue.

[mateuszviste]

so, while https://github.com/SvarDOS/bugz/issues/85 does provide an usability improvement (allowing users to rename the packages without impacting the way said packages will be installed), it is probably not a silver bullet for the kernel/command situation... Hence maybe indeed there is no better way than install kernels and shells in some separate subdirectories and instruct the user that they need to run some "ACTIVATE.BAT" file or such to actually switch the system to make use of the new kernel/shell.

[mateuszviste]

I think we should be good for now on this, right? So I propose to close it. It's always possible to reopen in the future should the current design prove to be flawed.

[boeckmann]

Yes, I agree.