> > For instance, you could put #warning pragmas at the top of each > > obsolete header so that the compiler spits out a warning when one is > > used. > > I personally fail to see how this would be superior rather than > complementary.
1. it achieves the original aim of alerting developers to their use of deprecated headers; 2. it still alerts developers who use deprecated headers even if you need to have compat-headers installed for some other reason (e.g., some user on your system is building 3rd party software that uses them) - the compat-headers solution fails completely in this scenario; 3. the errors themselves are clearer (a single "#warning: qlist.h is deprecated" is clearer than "error: cannot find header qlist.h" followed by a large flood of undefined types/etc); 4. it doesn't cause fatal breakages for users who just want to build some 3rd-party app and who aren't authoring Qt apps themselves; 5. it doesn't require root access (to install compat-headers) if you want to ignore the issue for the time being; 6. it doesn't give the impression that stuff that builds on every other system will fail to build on debian. So it achieves the same aim as the compat-headers split as seen in point 1, and in points 2, 3, 4, 5 and 6 it is a superior solution. I don't see any advantages that the compat-headers split has over #warnings. You could argue that by causing build failures it forces the issue to be dealt with *NOW*, but aside from being rude (IMHO), it could go one of two ways. Either the developer fixes their app, or the developer installs compat-headers for the time being (more important bugs to fix), at which point the errors go away and the developer forgets about it altogether. Anyway. This was all hashed out in some detail many months ago. I'm basically rehashing it just to answer your question. :) b.
