Re: Debian for Linux/{non-i386} / source packaging
On Sat, 9 Sep 1995, J.H.M.Dassen wrote:
> > How about doing this through a debian.rules Guidelines modification.
> > new-style debian.rules files might:
> [...]
> > That'd fit well with current build procedures, which should remain
> > unchanged:
> >
> > 1. Extract the sources.
> > 2. Change to the extraction directory.
> > 3. Type "make -f debian.rules { build, binary, diff, clean, ... }".
> > (perhaps releatedly)
> >
> > The approach chosen should allow current-style source packages to coexist
> > gracefully in the distribution with new-style source packages.
>
> That's true. But if I understand your scheme correctly, it still involves
> adding files to the upstream package. [...]
You're right, I didn't think this through. How about combining this
with a dpkg extension. Step 1 above would be something like
"dpkg --unpack <package>-<version>-<revision>" (or perhaps
the option might be something like --source or --dsource).
dpkg would look for a matching .dpatch.gz file and, if found,
extract the pristine sources and apply the debianizing patches.
Otherwise, with no matching .dpatch.gz file, it'd extract the
already-debianized sources. From that point, proceed as above.
For new-style packages, the directory with the debianized sources
should probably be renamed by dpkg from <package>-<version> to
<package>-<version>.debian, The diff target of the new-style
debian.rules file would then re-extract the pristine sources into
<package>-<version> and prepare the debainizing .dpatch.gz file
<package>-<version>-<revision>.dpatch.gz against that.
Perhaps an example would be clearer:
current-style:
package-1.0-5.tar.gz, package-1.0-5.diff.gz
dpkg --unpack package-1.0-5
debianized sources end up in package-1.0, as now
new-style
package-1.0-5.tar.gz, package-1.0-5.dpatch.gz
dpkg --unpack package-1.0-5
debianized sources end up in package-1.0.debian.
While working on the package, "dpkg --diff" re-extracts
the pristine sources, if needed, into ../package-1.0,
and does diffs against that to create the file
../package.1.0-<revision>.dpatch.gz, with <revision>
coming from debian.rules as it now does.
One issue with this scheme is the question of what the diff
target should do if ../package-1.0-<revision>.dpatch.gz
already exists. Two scenarios:
1. Maintainer extracts package, works on it, and rebuilds it
but has forgotten to change the revision number in debian.rules.
In this case, trashing the ../package-1.0-5.dpatch.gz file
needed to debianize the pristine sources to produce current
revision debainized sources is probably not the thing to do.
2. Maintainer extracts package, works on it while remembering
to change the revision number in debian.rules, rebuilds it
with binary, source, and diff targets. This produces
../package-1.0-6.dpatch.gz. Maintainer then decides he's
not done, does more work, and rebuilds. In this case, we
do want a to overwrite ../package-1.0-6.dpatch.gz if it's there.
One way to deal with this would be to introduce another debian.rules
target in new-style Guidelines. This might be named something li
"tidy" or "cleanup", and would use the package, version, and
revision info in debian.rules to delete the matching .tar.gz
and .dpatch.gz files in the parent directory. That's still not
bulletproof, though. A mistaken "make -f debian.rules tidy" before
changing the revision info in debian.rules deletes the .dpatch.gz
file we want to avoid deleting.
Hmmmm.... How about having the diff target produce a patch file
named ../package-1.0.dwork.gz instead of .dpatch.gz? Then we
could introduce a "commit" target to debian.rules, which would
rename it from .dwork.gz to .dpatch.gz. One single maintainer
mistake, then, wouldn't delete a needed file. He'd have to
rebuild without changing the revision number and then do an
explicit commit operation to cause the needed debianizing patch
file to be deleted.
Still safer, we could have debain.rules produce a patch file
named .dwork.gz, but not require a "commit" target in the
new-style debian.rules Guidelines. the maintainer would need
to rename the .dwork.gz file to .dpatch.gz for uploading.
Am I rambling, or making sense?
Reply to: