remove DOSDRIVE_D and drive_z?

[stsp]

I've finally got to review our installation and boot process, which, as always, means a big axe. I am puzzled about DOSDRIVE_D, lredir to Z: and mounting /home/$USER to D: by default. I don't know why these 3 steps are there, so I want to get them removed.

Bart, you added it, could you please explain a bit of rationale? Is this Z: trick useful, and is DOSDRIVE_D used by anyone? Does mounting /home/$USER to D: make any sense?

[stsp]

Open question.

In fact, since autoconf already contains dosemu2 as a name, and the spec file for fedora does the same, I believe the packager would have to have a really good arguments for messing around changing the name back to "dosemu". Also it may be quite confusing if people start to report dosemu2 bugs to dosemu1 tracker. Most important to note is the license difference. So there is probably no other way than to package it as dosemu2. The problem with that is that they'll likely have to drop dosemu1 then, as they use the same pathes... If that problem is to ever arise and they don't want to drop dosemu1, we can end up changing the pathes, which I really hope to avoid. So I'd say lets package it as dosemu2, see what problems arise, and solve them one by one. It is nearly impossible to package it as "dosemu". Anyway, this all is a distant future, so why to care.

[kalpha2]

which paths, paths to hold dosemu config, documentation, helper files? or paths to the (default) DOS to boot from? My preference would be dosemu2 has its own paths, as per previous comments I think it is relatively important to allow people to try out dosemu2 separately without disrupting an existing dosemu1 setup, and that potentially there may be need to be able to run both at same time.

[andrewbird]

I think most system paths would not be a problem I.e. /usr/share/dosemu2 /etc/dosemu2 etc, but the real issue will be /usr/bin/dosemu which I think would have to be maintained for script usage etc. Perhaps that's where the 'alternatives' package would come in, but I suspect that would mean repackaging dosemu 1.4 to be complient?

-------- Original message -------- From kalpha2 notifications@github.com Date: 25/05/2016 07:53 (GMT+00:00) To stsp/dosemu2 dosemu2@noreply.github.com Subject Re: [stsp/dosemu2] remove DOSDRIVE_D and drive_z? (#177)

which paths, paths to hold dosemu config, documentation, helper files? or paths to the (default) DOS to boot from? My preference would be dosemu2 has its own paths, as per previous comments I think it is relatively important to allow people to try out dosemu2 separately without disrupting an existing dosemu1 setup, and that potentially there may be need to be able to run both at same time.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

[stsp]

which paths, paths to hold dosemu config, documentation, helper files?

Yes. Of course you can use a different prefix, but this is not what the distro would do. The simplest solution would be to mark the 2 packages "conflicting" on a package level. Then people will be able to install either one.

paths to the (default) DOS to boot from?

This is hopefully unneeded, unless the backward compatibility is severely broken. Which is not quite the case yet, although the forward compatibility is broken completely and you can't easily downgrade dosemu2 to 1.

My preference would be dosemu2 has its own paths, as per previous comments I think it is relatively important to allow people to try out dosemu2 separately without disrupting an existing dosemu1 setup, and that potentially there may be need to be able to run both at same time.

Quite difficult as dosemu1 creates the symlink to reference the commands that are incompatible with dosemu2. But if they are marked as conflicting on a package level, it would be relatively easy to switch between, because one will uninstall and replace another.

[andrewbird]

Also a package manager 'provides' tag would be useful, allowing any other package depending upon dosemu to be satisfied by dosemu2 with 'provides dosemu' tag.

-------- Original message -------- From Stas Sergeev notifications@github.com Date: 25/05/2016 09:44 (GMT+00:00) To stsp/dosemu2 dosemu2@noreply.github.com Cc Andrew Bird ajb@spheresystems.co.uk,Comment comment@noreply.github.com Subject Re: [stsp/dosemu2] remove DOSDRIVE_D and drive_z? (#177)

which paths, paths to hold dosemu config, documentation, helper files?

Yes. Of course you can use a different prefix, but this is not what the distro would do. The simplest solution would be to mark the 2 packages "conflicting" on a package level. Then people will be able to install either one.

paths to the (default) DOS to boot from?

This is hopefully unneeded, unless the backward compatibility is severely broken. Which is not quite the case yet, although the forward compatibility is broken completely and you can't easily downgrade dosemu2 to 1.

My preference would be dosemu2 has its own paths, as per previous comments I think it is relatively important to allow people to try out dosemu2 separately without disrupting an existing dosemu1 setup, and that potentially there may be need to be able to run both at same time.

Quite difficult as dosemu1 creates the symlink to reference the commands that are incompatible with dosemu2. But if they are marked as conflicting on a package level, it would be relatively easy to switch between, because one will uninstall and replace another.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

[stsp]

I think most system paths would not be a problem I.e. /usr/share/dosemu2 /etc/dosemu2 etc, but the

Lets just hope this will not be needed. IMHO marking the 2 packages as conflicting is enough. But of course every distribution has its own rules. And I don't know how many do provide dosemu1. Maybe not too many to even bother?

real issue will be /usr/bin/dosemu which I think would have to be maintained for script usage etc. Perhaps that's where the 'alternatives' package would come in, but I suspect that would mean

I don't think many scripts are using dosemu, really. Until very recently I thought there are none. Not quite: openwatcom does... Is it enough to mess with alternatives, is an open question. And in any case, to go as deep into troubles as we are discussing now, some distro should come up with that problem. I don't think this is very likely to happen, so maybe there is no problem at all.

[andrewbird]

I also believe dosemu2 should be a full replacement for dosemu1. Does anyone have a list of things that dosemu2 doesn't work with or provide that dosemu1 did well? If there are items, then probably these should be raised as issues and fixed. 

-------- Original message -------- From Stas Sergeev notifications@github.com Date: 25/05/2016 09:44 (GMT+00:00) To stsp/dosemu2 dosemu2@noreply.github.com Cc Andrew Bird ajb@spheresystems.co.uk,Comment comment@noreply.github.com Subject Re: [stsp/dosemu2] remove DOSDRIVE_D and drive_z? (#177)

which paths, paths to hold dosemu config, documentation, helper files?

Yes. Of course you can use a different prefix, but this is not what the distro would do. The simplest solution would be to mark the 2 packages "conflicting" on a package level. Then people will be able to install either one.

paths to the (default) DOS to boot from?

This is hopefully unneeded, unless the backward compatibility is severely broken. Which is not quite the case yet, although the forward compatibility is broken completely and you can't easily downgrade dosemu2 to 1.

My preference would be dosemu2 has its own paths, as per previous comments I think it is relatively important to allow people to try out dosemu2 separately without disrupting an existing dosemu1 setup, and that potentially there may be need to be able to run both at same time.

Quite difficult as dosemu1 creates the symlink to reference the commands that are incompatible with dosemu2. But if they are marked as conflicting on a package level, it would be relatively easy to switch between, because one will uninstall and replace another.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

[stsp]

I also believe dosemu2 should be a full replacement for dosemu1.

We can only hope that distributions will think the same way. In fact, I am pretty sure they won't think about this at all unless we do all the packaging work and submit them a package. In which case we are quite free to do what we want, and what we want is likely to mark a conflict with dosemu1 and "provide" dosemu1 as a dependency for others. Hmm, any package depending on dosemu? I hope not, so even this likely won't be needed.

[jschwartzenberg]

Stas' point about other VMs makes a lot of sense. The VM which comes the closest to dosemu is probably Merge/Win4Lin which I think did provide the home directory on a higher drive letter by default, but in general VMs do not do that. The -home switch seems a bit silly to me (why special case the homedir?), maybe if you could specify a drive letter (as an optional argument so it would stay compatible) it would make some sense. I don't know how much influence dosemu has on which drive letters are assigned though.

I'm trying to test as much as I can in dosemu2 and report every issue/regression I run into. I really hope dosemu2 can be a full replacement when it's released. In case regressions are found after release, considering the rate at which bugs are fixed now, I think it's more important to provide up to date dosemu2 packages if it turns out that distros won't manage to keep up with dosemu2 bugfix releases. Trying to run 1.4 in parallel should not make sense.

[kalpha2]

There are obviously potentially many different user/dev usages and therefore opinions. Personally unless you could guarantee it was 100% backward compatible (which I don't expect you should have to) then I think it should be independent and able to parallel run. Much as I have some who run some stuff in dosbox and some in dosemu.....

<> uninstalling and reinstalling is (hopefully) clean (though I wonder what some distro's "completely" remove option would do/cause) but not necessarily easy to switch between ... i.e. if you were constantly (having) to do it.... and ideally wanting to be able to parallel run. certainly don't like the idea of package conflict...

<<And I don't know how many do provide dosemu1>> don't know ... but I float between PCLOS, Debian and Mint ... and they all have...

[stsp]

probably Merge/Win4Lin which I think did provide the home directory on a higher drive letter by default,

What do you mean? Are you a win4lin developer or a packager to make it a default, or do you mean you have just configured it that way on your PC?

The -home switch seems a bit silly to me (why special case the homedir?),

Just for compatibility. It was there for too long, and, as you can see, people are defending as hell on it, even though I agree it is completely silly. Please note that this option is purely in a "dosemu" wrapper, not in a code. And a wrapper is exactly for that kind of compatibility things. Keeping it in a wrapper is not a bit deal, and, as long as it makes people happy...

Trying to run 1.4 in parallel should not make sense.

We can't always push our decision to distributions. We can advise them so, we can submit the package that does this, etc, but we don't have the final word. But this discussion is mostly theoretical, as I don't expect any distro to make a problem out of replacing dosemu1.

Personally unless you could guarantee it was 100% backward compatible

As of yet, it is supposed to be 100% backward compatible, and 0% forward compatible. If this will change, I'll open a new ticket with explanations etc. So far I don't expect myself to go crazy and break the compatibility willingly.

[jschwartzenberg]

What do you mean? Are you a win4lin developer or a packager to make it a default, or do you mean you have just configured it that way on your PC?

Their default config had it set up that way.

[stsp]

Ah, right, bad reading on my part. Do you know what was the intention of providing that?

[jschwartzenberg]

Thinking more about it (it's been a while since I ran Win4Lin), I think they also created a directory like mydata inside the homedir and pointed the win9x 'My Documents' folder to that directory through a drive mapping. Basically the same as the proposed ~/dosemu directory. Maybe there was indeed no way reach the full home directory directly or they just mapped the root dir.

What was notable though, was that the C: drive was put in ~/win. It would be like having dosemu's C: in ~/dos, so obviously reachable for the user.

[stsp]

OK, then this example doesn't count as you are not sure the entire $HOME was exposed.

[jschwartzenberg]

Yeah my apologies. It's great you're brainstorming such much about all these things here though. I think it will show in dosemu2's final release!!

[stsp]

it will show in dosemu2's final release!!

We can have wiki pages to document what people think is important. Does anyone want to create wiki pages? I think we can track many things, and what I personally don't always remember is what kernel changes we are depending on and when did they happen. That would be good to have documented. There are short-cuts possible, for example the wiki page can have just a brief explanation and the references to the comments in the issue tickets.

[stsp]

Even newer syntax, after recent commits: dosemu -dumb -qE dir >listing

After another round of openwatcom fixes, the syntax is: dosemu -dumb -quiet -E dir >listing

Good that I can now define the syntax based on the real use-case, and on the real problems people are having with building openwatcom. Rather than on a compatibility concerns. https://github.com/open-watcom/open-watcom-v2/commit/04e00568e16fec968afb8b74ea754368491ea10e

[jschwartzenberg]

We can have wiki pages to document what people think is important. Does anyone want to create wiki pages?

I wouldn't mind doing that, but I'm not sure whether I'll be able to spend enough time on it for now. I hope to spend more time on testing & freedos install soon. I think a wiki would definitely be useful though.

[stsp]

As of yet, it is supposed to be 100% backward compatible, and

... and for default setup only. It is important to note that custom autoexec or some user scripts on unix side (except openwatcom which I care about) can already hit (usually trivial) incompats.

[stsp]

Personally unless you could guarantee it was 100% backward compatible (which I don't expect you should have to)

But instead we can guarantee that all your practical compatibility problems will be considered in this tracker, and likely also fixed. That guarantee should work much better for you than the theoretical guarantee about 100% compatibility. Because if you are really concerned about the 100% compatibility, there is no point to upgrade to dosemu2, and you should keep using 1.4 as then you really have 100% compatibility with what you have now. The "conflict" solution in the package should work fine for you then, as it will allow people to install either one. Since I won't (will not) "push" any distro to abandon dosemu1, this compatibility option should work very well.