[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] directory for config files.



> > avoid confusion. I'm sorry, Guido. I disagree completely with your
> > example.

> I never said that I would recommend such a setup.  

Apologies, Guido. I read it that you did. Sorry.

> No matter if it's good or bad, I don't consider that search path to be a
> menace. So why change it?

This does raise certain questions though.

Scenario:

An Atari enthusiast wants to install MiNT. They are not aware of
SpareMiNT, KGMD, TAF or any other of the distributions that the majority
of us are familiar with. They just have the 'Multitos' disk that came with
their Atari. They install this, and in c:\multitos they have an xdd, that,
for the sake of this example, doesn't work with a 1.15 and later kernel:
it causes the boot process to hang. This, of course, is not a problem, as
they are using the Atari-supplied kernel, 1.10 (or something).

Then they discover 'NutMiNT' - a new FreeMint 1.17 kernel-based
installation package on the web. They download it to their hard-disk, and
run 'nutmint.tos', a renamed mint.prg of the kernel, 1.17. This
nutmint.tos, will load all *.x?? in '.', 'c:\mint' (if it exists) and the
incompatible xdd in 'c:\multitos'. And nothing! The boot procedure of mint
fails. They have to reboot. The same thing, over and over again. Now this
person is not afraid to ask question, so they send an email to the
mint-list, describing what happens. Some of us are successfully using this
NutMiNT distribution, and can't understand why it would fail at this
stage. This newbie, gets dissolusioned(sp?) after a couple of days, and
just plain gives up, maybe even sells their Milan/Hades, whatever.


(what a load of waffle, me thinks! <grin>)


An idea has occurred to me, writing this. What about, if we had a
compile-time option for the kernel, -DDISTRIBUTION, or something. This, if
defined, would limit the search path to '.' for mint.cnf and *.x??. This
would be simplicity itself, to implement into the current kernel. Under
normal circumstances, this would never be defined and binary distributions
should never be released with this. But, anyone preparing a distribution,
could compile with this option. That way they would know for sure what was
being loaded, blah-de-blah, and the above, highly contrived, but quite
possible, scenario, would be avoided.

Then again, if a distribution-maintainer is going to recompile the
kernel, they could always modify the source so that it only checked '.',
but that's a lot more hassle, that just adding a #define to the Makefile.

Thoughts on this, anyone?

Personally, the search-path does not bother me, but, now with my
distribution-maintainers hat on, I am bothered by the search paths, and
would want to control it precisely.

Salut/.

J/.
__
John (ligotage) Blakeley