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.
Ack.
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
Ack.
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:
Makefile.am/configure.ac)
[...]
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
format.)
[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.
Regards,
Philip Ashmore
Reply to: