==================================== 1. .mdeb or .emdeb Julian asked:
>1. Why .mdeb and not .emdeb? I think the latter would be clearer. Phonetically, emdeb == mdeb. I originally preferred .emdeb but other emdebian/debian developers preferred the shorter version and it is sufficiently different to the other current alternative .deb, .udeb
True, but the 'u' in '.udeb' is AFAIK intended to be the Greek 'mu' meaning micro; it is fairly standard practice to use a 'u' in place of the letter 'mu' when only ASCII is available. I see no particular reason to not use '.emdeb'; who knows what other .deb variants may appear in the future, and .emdeb is completely clear and unambiguous, whereas .mdeb is not quite so.
Ultimately, the .emN is intended to be the primary indicator that this is an emdebian file as it's portable to all other package related files and doesn't break existing tools, whereas .mdeb is deliberately intended to prevent certain tools from using the binaries without user intervention.
Indeed, but the suffix is easier to spot that an embedded emN string inside the version number. And '.emdeb' is more instantly understandable than '.mdeb'. ======================================== 2. emN.diff.gz or emN.emdiff.gz ?
>2. Would it be worth called the emdeb diff file .emdiff.gz or > .em.diff.gz so that it cannot possibly be confused with a > standard Debian .diff.gz? Possibly; the current scheme relies on emN. I think .em.diff.gz is preferable to .emdiff.gz but it does look a tad strange: qof_0.7.2-1.diff.gz becomes (as the scheme is now) qof_0.7.2-1em1.diff.gz or on to (with a renamed diff): qof_0.7.2-1em1.em.diff.gz Hmm, me thinks there's duplication there.
My concern is this: with just qof_0.7.2-1em1.diff.gz, dpkg-source could attempt to extract qof version 0.7.2-1em1, could it not? Or would the .dsc generated prevent this? Until dpkg-source v2 arrives, we cannot handle multiple diffs. Naming the diff file as .emdiff.gz or similar means that the regular dpkg-source would probably just bail out or do something like not patch at all, so there is a failsafe scheme built in place. ===========================A quick test shows that there are problems. Using qof_0.7.2-1em1.diff.gz, dpkg-source unpacks the source *without* being able to cope with multiple diffs. So the emdebian diff would try (and fail) to be applied against the upstream source *without* the debian diff being applied first. No debian/ directory would exist, except with native packages. One way around that is to include the entire debian .diff.gz in the emdebian diff.gz but that makes maintenance complicated.
Using qof_0.7.2-1em1.emdiff.gz causes duplication in the filename but prevents mishandling of the emdebian package.
qof_0.7.2-1em1.em.diff.gz works too: $ dpkg-source -x qof_0.7.2-1em1.dscdpkg-source: warning: extracting unsigned source package (./qof_0.7.2-1em1.dsc)
dpkg-source: error: unrecognised file type - `qof_0.7.2-1em1.em.diff.gz' ======================================= 3. Extent of emdebian changes in our diff.gz (whatever name is used)
I'm not expecting any emdebian packages to require patches to beapplied outside debian/ - the package itself will have to build on arm before it is considered for emdebian anyway. If upstream don't provide ways of *not* building generated documentation via ./configure switches, emdebian may simply have to let it build and then delete it. A suitable bug report could then help things along.;-)
Yes, but you told me that it might be difficult to build emdebian packages if huge amounts of stuff are needed to build the docs. So you might well end up modifying stuff outside of debian/. Or there may be other reasons. Please don't assume from the outset that you won't need to, or you're going to paint yourself into a corner pretty quickly when you discover that you need to. ========================================What's the feeling on ? Should emdebian builds need to patch anything outside debian/* ? Am I just being overly cautious in expecting problems building docs that we later ignore? (I'm thinking that emdebian packages could be held up by problems in packages that are used only to build the docs that we don't need, as well as the extra compile time required to build unwanted files.)
I'd rather suffer a protracted build than have to modify stuff outside debian/* - it's something to keep in mind. Don't know quite how to resolve it just yet. This is on the principle that the less changes we need to make for Emdebian, the easier everything else becomes. If we start poking around in the main source tree, bugs become much harder to fix.
-- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Description: PGP signature