[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A common configuration format, anyone?

On 14/11/12 06:48, Chow Loong Jin wrote:
On 14/11/2012 13:43, Philip Ashmore wrote:
Hi there.

As someone who develops software for Debian I encounter situations where I have
to specify the same information multiple times, and when that information
changes I have to remember to update it in each of these places.

Just now I had to add a debian/*doc.postrm.in to one of my projects.
Makefile.am - save the *in file in EXTRA_DIST
configure.ac - convert the *.in to a *.

Why are you generating debian/* files from within the upstream build system?
That's just wrong. Packaging is packaging. Upstream matter is upstream matter.

Also, you don't need to add the file into EXTRA_DIST if you've already added it
using AC_CONFIG_FILES -- autotools does that automatically.
Now that's the kind of thing that semantic validation/constraints that I'm talking about. If Debian had a wizard where you could go to "add pre-processing file" it would eliminate such typos.

Git - add to version control.


makefile - new version

If you generate your upstream tarball with autogen/make dist, you should never
have this issue.
The build system I've developed has a top-level "makefile" that stores the version, short and long descriptions. It's easy to communicate using terms one is familiar with and forget about transposition and assumed knowledge.

NEWS - what's changed
ChangeLog - what's changed

Autogenerate this from git log. Some upstreams don't bother with this, even.
I must look into this sometime. Glad to know.

Git - store the changes


As you can see, you're uselessly repeating steps that can already be
automatically done today, in addition to doing it just plain wrong (re:


That aside, I have nfc how to interpret your proposed text file thing, but GNOME
has something similar, called DOAP files[1], which albeit in XML format, are
more readable than yours.
It's a simple format which, like xml, is human-readable but that's just a plus - us humans prefer to interact with the content efficiently rather than be bogged down in the representation.

I plan to use the format to allow more expressive graphical representations to be developed. Plus, the binary form can be transformed using the "sbd" tool/example packaged with v3c-storyboard, but these are all baby steps to being able to develop interfaces with it that can interact with the "real world" and transform content - including (different versions of) themselves.

This format can be interpreted using libffi to define closures - interpreted functions, as the sb/tests/hello-world4-test program shows.

Then those functions can be transformed into executable code using LLVM as the hello-world3-test program shows, so I hope it will be easier to do rapid prototyping with than html5/JavaScript, because you use one visual representation to modify something elses visual representation, which could be anything.

(And finally, like Ben said, please don't ask anyone to package anything in this

[1] https://live.gnome.org/MaintainersCorner#maintainers

I wasn't thinking of asking anyone to package software in this format - sorry if I gave that impression.

The packaging tools used by Debian and others have a steep learning curve because their representation isn't human-friendly - it's all for the convenience of a build system dating back to UNIX.

I'm talking about a graphical interface that generates these files so that developers never have to look at them.

In my opinion anything written in (ba)sh or m4 is just asking for a typo to do the unexpected, which is a fundamental flaw of textual representation.

My goal is to narrow the grand canyon of a gap between how graphical interfaces do such a great job of hiding the details, to the way we develop them, which is all about the details.

Whether I achieve anything like that is another matter, but I don't see any huge obstacles in my way.

The idea is to have a Debian/Fedora/AnOther "portal" where you're basically hand-held at every step in the process if doing whatever you want to, from system configuration to developing packages.

The other approach, the one that was there since before GUIs, is the mailing list.

Philip Ashmore

Reply to: