Are all package loading conflicts due to conflicting identical control sequence names?

Question

I just ran into a load-order conflict due to identical cs names and realized that this is the source of similar problems in the past that I've seen. Thinking about it, I can't imagine what other conflicts there could be, so that shows you how much I know. Anyway, now that I'm writing a package or two I need to understand this.

-------------- After Reading Answers ------------------

Well, I feel like my question was answered fully and to my complete satisfaction. Unfortunately, all of the answers contributed to my current understanding and feeling of satisfaction, and I don't feel that it would be fair to select only one as the 'correct' answer. So, until I hear a way out of this conundrum, I want to symbolically check all of the answers and thank everyone who took the time to answer me.

Thank you.

Answer 1

The most common problem, as you correctly said is duplicating macro names. This you can easily check with a commands like \@ifundefined or ifdefinable and other similar commands. The problem is similar to problems experienced in normal programming with globals. Generally globals are bad and with TeX programming they are used all over the place.

You can mitigate problems by namespacing your macros. For example you can use @bev@pagewidth, comfortably as it is unlikely that anyone has used this in another macro! This makes your macro names rather long which makes people from a Java background happy, but people from a `C' background get very unhappy.

LaTeX3 provides all sorts of methods and rules and regulations to namespace and create commands. It has a syntax as unique as that of TeX's own and although rather off putting at first - you can really be up and going over a weekend. The Team has put a tremendous effort in bringing it so far that you can use it right away - saving you lots of hours of work.

If you have to override any existing commands, be a gentleman save them first in a variable and restore them back at the end of your package's code.

Any changes to dimensions, glues, counters and the like are better defined locally.

The last item of concern is key value pairs using keyval here again if you use it you need to be careful with allocation of names. Also decide with which packages you want to interact so that you can avoid conflicts.

Answer 2

Packages that try to take control of what happens at Tex events like \shipout can conflict in nasty ways. Latex doesn't really have an orderly way to resolve these conflicts, so package writers need to work with each other.

Example: {hyperref} has had a number of conflicts with packages for this reason, see http://tug.org/pipermail/texhax/2010-June/015250.html

These examples aren't naming conflicts, because changing choice of names can't fix them. You need to change what you are doing.

Some possible other ways of getting package conflicts, that I haven't seen realised:

1. Messing about with catcodes could cause conflicts in principle. You'd think that packages like {inputenc} that do hairy things with catcodes would be at risk here, but I don't know of any.
2. Packages that run Postscript/PDF code through \special commands, like PGF does. Lots of room for conflict here, but I don't know of any actual package conflicts in practice.

Answer 3

One common problem is the redefinition of auxiliary macros: e.g., hyperref redefines internals of the counter mechanism so that hyperlinks work, and all counters defined before \usepackage{hyperref} don't benefit, but I don't know if that would fall under "conflict" for you since it's not usually something that causes compilation to fail, just the results are not what one expected.