Uploaded new package: yada
I've now uploaded a packaged version of YADA, the packaging helper
which I RFCed you about a couple of weeks ago, and which surprisingly
(to me, anyway) got a mention in Debian Weekly News. Woo!
Lots of random thoughts follow. Let me know if you have comments. If
you're willing for the comments to be public, please submit them as
wishlist bugs against "yada"; it'll make it easier for me to be sure I
don't overlook them.
Some of the comments I got already:
- Why do I have to write ../configure when I mean ./configure? That's
stupid.
Yes, I suppose it was. It's now fixed so that an initial dot is
stripped only from lines containing only dots. Hopefully this makes
more sense.
- If you're trying to make your packages file like an RPM spec file,
why don't you put the changelog in there too? RPM does that.
Because I'm not trying to make it like an RPM spec file - I've never
packaged anything using RPM, or even looked very deeply at it, so any
similarity is (mostly) coincidental. I really think the package
changelog is one meta level "up" from the stuff in debian/packages, so
I don't put it in debian/packages. Besides, I don't want my packages
file growing without bound. Think about it; eventually, you'd have to
scroll past miles of changelog before you got to the meat of your
packages file. There are tools to edit debian/changelog easily, anyway
- Emacs modes and such (not that I use them). They wouldn't work if
the changelog was embedded in another file.
I might consider making it optionally possible to put the changelog in
debian/packages, if there's the demand, but I still wouldn't advise
anyone to use that feature.
- How do I easily create lots of directories under $ROOT?
I didn't think of that, since I normally install everything in my
packages "by hand", disregarding the upstream "make install"; using
"yada install" for this, you don't have to explicitly create
directories. When I do use "make install", it usually creates all the
necessary directories itself, so I rarely need to create directories
explicitly. If this is a problem, I'll work something out; see "For
the future" below.
- Why do I have to put yada in my debian directory?
'coz it was easier to do it that way while I was writing it. Nobody
had yada installed, and I didn't want to break all my source packages
for everyone else. Also, yada's likely to change a lot as I work out
how it should work, and this will make sure the version used to build
your package is the same as the version that generated your
debian/rules.
I hope I'll eventually be able to allow either way, so that you can
hack your own copy and put it in debian/, or use the installed
version.
- Package it!
All right, all right! ;)
- You should allow commands starting with "-" to fail like make does.
Good idea. I was toying with the idea of a new script type, "make",
which would, amongst other things, allow this (and which would result
in prettier generated rules files).
- Why do I need to write a description for the source package, too?
The source package description field isn't really what it says it is.
The first line is used in the copyright file, as the title of the
package; the rest is tacked onto the start of the description of each
binary package. Mostly, you'll want to have no description for the
source package, apart from the one-line title.
At least two people seem to have misunderstood the source description
field. I should really split it into two fields, perhaps "Title:" and
"Description-Prefix:" (or "Common-Description:") or some such.
- Why is "Major-Changes:" required? Sometimes there aren't any.
The reason it's required is to make you think about whether there were
any changes worth documenting. If there aren't, leave the field
blank. I never used to mention any changes in the copyright file,
because I didn't remember. I hope yada will remind me.
If the package is native, "major-changes" isn't required (I hope).
- You should do something about init.d scripts.
Indeed. One idea I was sent was to have fields called "Init-Start:",
"Init-Stop:" and so on. The init.d script would be built out of these,
and update-rc.d called at the appropriate points.
Changes to yada since the version in
http://master.debian.org/%7Ecpbs/yada/:
* Packaged and released.
* More consistent handling of fields with empty first lines.
* If the copyright licence of the package isn't standard, the first
line of the "Copyright:" field should now be a single dot, rather
than being empty.
* I thought that install-docs could cope with several documents in one
doc-base file. It can't. Yada now looks for "Document:" tags
within the doc-base field, splits up individual doc-base files, and
calls install-docs for them each separately.
* Bomb out if we see an unrecognised field in debian/packages.
* "yada install -script" added (equivalent to "-bin -unstripped") to
ease installing of binaries without having them automatically
stripped.
* Yada now elides some otherwise useless junk from debian/rules if (a)
there are no build-depends or build-conflicts, or (b) there are no
packages specific to particular architectures.
* More error checking in the compression and symlink clean-up phases,
and fixed a nasty bug therein which would corrupt any symlink with
"../../" in its target string, such as "undocumented" symlinks from
X11 manpage directories.
* New command "yada yada", which copies or updates the yada script in
your debian/ directory, and creates a skeleton debian/packages for
you if you don't have one already.
* Made a start writing some man pages.
* Miscellaneous bug fixes.
Yada's goals:
- Be declarative, where possible, not imperative
- Provide a way to bypass anything that yada does automatically
For the future:
- Support init.d scripts directly.
- Integrate nicely with suidmanager.
- Don't require yada installed in the package's debian/ directory.
- Allow "make"-style commands in executable fields.
- Rework package description handling.
- Work out whether the constrained form of yada's generated copyright
files is actually a Good Thing or not.
- Generate rules files which don't need yada at all, either installed
or in debian/.
- Maybe generate rules files which use debhelper.
- I'm going off the idea of "yada install". It doesn't really fit in
with the rest of yada. I'll try to some up with a declarative
syntax to describe file installation.
- My reading Debian policy is that the files listed in 'conffiles'
must be exactly every file under /etc/. If this is right, there
should be no reason for 'conffiles' not to be automatically
generated, with no further input.
Urgh. I really ought to get on with my work now...
Thanks for reading,
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
Reply to: