(This probably belongs on debian-discuss but I'm not subscribed there -- feel free to crosspost if/when you think this is worth discussion. Probably after slink is stable would be better.)
On this note -- Arto is right that we are hard pressed to standardize source packages given the diversity of technique used in writing code. Adding source dependencies deserves thought and can be acheived, despite the complexities (for example certain packages may be required to build certain binary packages from a source, but not required to build other binaries, and the Debian source should be able to inform the person compiling the package of this at least during compilation, or better during installation of the source.) But what about developing a standard and/or guide for new source code? That is, developers writing new packages with Debian as their principle (or at least, a major) target OS. A set of guidelines for writing new Debian packages from scratch would not only help developers make the right tool/structure choices, but might serve as a model towards which upstream developers of existing packages can strive if they are so inclined. This kind of standard would be most crucial in freeing packages from frivolous dependencies. For example, a lot of graphics viewers are hard-linked to image manipulation libraries rather than loading them runtime, e.g. you _have_ to have JPEG support even if you do not wish to view JPEGs. While I definitely won't hold what the GGI project is doing up as a model source code tree, because the tree we have there is still pretty messy, the basic concept of how LibGGI maintains binary compatibility between different graphics and IO targets is a good example of how this problem can be dealt with. The key point is to avoid compile-time configuration of features that are not portability related, so a binary package can be fully featured and two different packages are not required (e.g. cdda2wav and paranoia), but at the same time it doesn't bloat the system by relying on too many other packages. A guide on how to portably write plug-in style code would help a lot. But at the same time this is treading on thin ice; it invites a lot of religious flamewars between different coding philosphies and toolsets, literate programming vs. separate documentation; the pros and cons of autoconf, licensing, etc. How to provide maximum flexibility for coding philosphies but still get a uniform source code structure deserves quality thought. So I'd urge anyone thinking about this to excercise tact in keeping the discussion on topic. P.S. The GGI project had a lot of wasted time arguing about licensing issues. The discussion was sometimes heated and monopolized the mailing list at times. This can hamper group development a lot, so I think the first thing that should go in such a standard is an informational "developers guide to licensing" that fully and accurately gives the pros and cons of any major licenses and their various revisions, such that a developer can make an informed decision about what license to choose for their new package and know all the issues they face when linking to other packages with different licenses. Hopefully such a document could cut down the time such arguments consume. I think the Debian Project (with the assitance of those on the USENET licensing related groups) would be the perfectly appropriate progenitor of such a document. There is already IIRC some material in the Debian developers guide but something more like a pre-chewed "consumers guide" style cheat sheet that a developer can make an informed decision from in a minimal amount of time. -- Brian S. Julin
