Re: Deb structure - general question
(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
Reply to: