pkg should resolve the package name based on the LSM file inside

[mateuszviste]

Currently pkg uses the package filename and performs its check based on that. Instead it should perform a lookup inside the package, read the appinfo/*.lsm filename and use that as package name.

This will allow the user to store different versions of the same package and upgrade/dowgrade it at will (eg. FDISK100.SVP vs FDISK110.SVP).

More importantly, it will also allow to distribute (via pkgnet or otherwise) different packages that resolve to the same "virtual" package name, that is packages that provide the same feature where only one can be installed at any given time. Examples:

• KERNLEDR.SVP vs KERNLFD.SVP would both in fact resolve into a package named "KERNEL".
• COMMSVAR.SVP vs COMMFREE.SVP vs COMM4DOS.SVP vs COMMDOG.SVP could all resolve into a package named "COMMAND".

Such approach would allow the user to switch between different vendors of a given feature without the risk of leaving the system in a kernel-less or shell-less state. It would also make the kernel / command switching automated, ie not requiring the user to perform any kind of activation or installation besides a single "pkg update kernledr".

[mateuszviste]

As mentionned in SvarDOS/edrdos#58 there are two major issues with the concept of "virtual" packages:

1. Bernd pointed out that having many packages resolve to the same name might be confusing to users and it would make it non obvious which "vendor package" exactly is installed
2. Pkgnet would also be confused because it would see that a package "kernel" is locally installed but would be unable to guess what real package it relates to (edr, fd or else) so checking for online updates would be impossible.

This feature is still desirable for the improved userfriendliness it provides, but using it to distribute "virtual" packages is likely not a good idea.

[mateuszviste]

done