I was more thinking about lazarus' "Online Package Manager" kind scenarios, where maintainers allow this and write the actual lpks.
I am/was approaching it at a broader level. This is also an issue for fpc's package manager (which afaik OPM uses as mechanism as well).
Of course, in case you are in control then you can 'fix' some of the issues. What about those packages not being maintained (by OPM) ? There I have commercial packages in mind, for instance.
In the end, some side gives and renames. Very old and established commercial packages might force OPM managers to think twice. New commercial packages face an avoidable support problem if OPM persists because of backwards compatibility, forcing them to think twice.
There is no solution for that indeed, since it basically assumes "anything can happen", and package maintainers not regarding any rules.
You could of course argue that commercial entities should not be using general used unit names, and should always be using dotted ones but is that being advertised in an official manner or are there instructions ?
I didn't mean to suggest everything should use dotted. I suggested this for a case where there are two forks of the same package (dmath/lmath) with resulting unit clashes.
As already mentioned by yourself, even the FCL itself seem to run into this issue.
Release versions are compiled -Ur which avoids searching for source for FPC units.
But there are more such cases, e.g. both lazarus and FPC's FV unit have a "dialogs" unit. There have been other clashes too, iirc between FV and Mac OS X specific units.
FV features hopelessly general names like drivers/editors/dialogs/time/resource/gadgets/validate/views/app. Unfortunately it is mostly used by the most helpless of users, in the most helpless of IDEs (textmode IDE).
Not to mention that whenever the fcl get's extended (either by using dotted names or not) that it could happen that the chosen prefix (or lack thereof) clashes with an already existing package that has been there for years (just a random example, please also see that it in a broader view e.g. lazarus packages etc)
Since everyone seems to be putting up their own package of what they believe is the right way to implement/solve certain topics there is a higher chance of such "name clashing" related issues.
Well, they are still quite rare, and most resolve themselves on first realization of the conflict. And that is still the most preferable scenario, since that doesn't need continous configuration management by the user.
I understand this topic has probably been discussed a zillion of times before but my question is more if it could be solved. Should it be solved ? And in case it does, could it then be solved in such a way that it actually makes sense ?
I don't believe in a solution to end all solutions, if only because that leads to hard to maintain configuration. It only benefits the kind of people that can also workaround it other ways.
Maybe some minor guidelines to decrease the likeliness. In time OPM also helps, since if it contains the bulk of Lazarus shared source, testing if an unitname is occupied is easier
For instance I was more thinking along the line of a "namespace" for an individual package, that could be changed at will. It does not imply an approach as used by .dot languages, rather a more direct one that allows the user to "select" a particular package by using it's namespace, preferably by allowing aliasing for them as well in case portability / compatibility is required.
If you want to make a proposal, be warned that it is not simple because the compiler rarely has an overall overview. It only searches units it needs, and programs may be compiled in multiple steps with varying parameters. (paths, default namespaces). A good understanding of how the unit system works (as in the order of processing, not the syntax) is paramount.
Pascal is halfway between C/C++ (which needs oodles of external build tools, and even then most source only meets at the linker), and Java/.NET with their carefully collections of class hierarchies, each mapped on a directory structure. (though to be honest, I don't know the real nitty, gritty rules for compilation in Java/.NET either, but I assume it is more likely to get access to all program parts at once )
Whatever the case, I thank you for the ack and feedback marcov.
No problem. The unit system always fascinated me as it is quite elegant and major component of Pascal. Some nice parts of it haven't been backported from Modula2. Maybe one day....