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