I disagree. There is more than one way to create a mess. One is what you describe! The other one you get by over-engineering things. If you create a configuration for every package that consist of one file only you will get tons of configuration files with hard to maintain dependencies. A bigger mess in my opinion (and experience). You always have to leverage the use and effect of doing things. Configurations can have groups which is an internal separation of things that belong together. As there are more ways to do it I have trouble understanding the "if each package move its clients...". There is no need to have a single approach. If it would be that way it would be good if pharo would just follow ANSI.
So then why not having a single one? I do not use Sixx. But I use XMLParser. So do you think that I can maintain pastel, sixx versions that I do not use? So do you think that having a large configuration with parts that are unmaintained is good? I do not think so. So I will create a ConfigurationOfXMLParser.
Sixx is a serializer/deserializer for XML and therefor is using streams. Streams are one of those fine examples where platform differences can drive you nuts. I couldn't understand all the fuzz of not using sport and preferring grease for seaside but only for seaside etc. I had a hard time dealing with platform subtleties for character encoding (yes, I care!) and streams when it comes to dialects. So I decided to introduce grease and made the GemStone port of Sixx depend on streams and character encoding behaviour of grease (Please sue me!). Dale was so kind to make even GemStone Core to depend on Grease to make Xml loadable by the core.
But put that in ConfigurationOfSixx :)
Well, just do it.
I do not use Sixx. But I use XMLParser.
I personally would put xml parser, sixx, pastell, other xpath libs and the pull parser in a single configuration file. If someone likes to do XML stuff he/she will be fine to find it maintained in a single place. All of the mentioned libs are single packaged, tiny things. This would probably also help to find an existing lib before implemented your own (search for xpath in the mailing lists). I understand you are looking for something "clean". Well, knock yourself off. I'm more after usable units.
No I'm looking for usable things too and when I load configurationOfXML to get the parser I'm not interested in the clients of XMLParser, else you should also put Soup and a couple of others.
Norbert
Later I recognized that in pharo terms this is not possible. I had a discussion with Sven because I wanted to have a zinc port for gemstone. But he was more interested to get zinc close to pharo. So the grease way was not an option and the result is the port to gemstone is still incomplete and hard to maintain.
Sorry for the long answer but this is just another story of how hard it is to have modular systems where all of the mentioned issues wouldn't be that much of a problem. I would wish that we find a good solution to make sources more interchangable between platforms. I don't mean get rid of the dialect differences (because I don't think it will happen) but to design code in a way that platform subtleties can be compensated in an object oriented way.
Norbert