Proposed scheme for emdeb source structure
Hiya all!
Well, things have quietened down a little, so I'd like to propose the
following. I'm sure I'll leave stuff out or forget stuff - that'll
become very clear as I try to code stuff. Please also remember that
there are two very distinct groups of users: developers (who want to
modify the emdebian patches) and users (who just want to download and
build). Of course these groups will overlap, but the tools for these
tasks are distinct.
We start with developers.
Default directory structure
---------------------------
<emdebian working directory>/
emdeb-patches/ -- this holds the SVN repository of packages' patches
package1/
.svn/ -- SVN metadata
ALTERNATIVE 1:
package1.em.diff -- the emdeb diff file for package1,
representing the unified diff between the
Debian version of the package and the emdebian one
ALTERNATIVE 2:
file1.diff -- every file which has a diff is stored separately.
debian/ They are all made by appending ".diff"
rules.diff (except for debian/changelog.emdeb) - and obvious
changelog.emdeb special cases if there's a file which ends
".diff" already present in the package
package2/ -- same layout
...
This way, someone wanting to download the SVN emdeb repository for a
particular package to work on it doesn't have to download the whole
repository.
<work-area>/
package1/
build-area/ -- for building the packages, as in svn-buildpackage
tarballs/ -- contains .orig.tar.gz and Debian .diff.gz files
package1/ -- working source tree with emdebian patches applied
Makefile
foo.c
debian/
control
package2/ -- the same layout
...
Workflow/tasks
--------------
We work with the package called package1 throughout the following.
(1) Setting up a package work area
Script which:
- creates the directories package1/{build-area,tarballs,package1}
- runs apt-get source to get the Debian sources (this may be from
upstream Debian for a package new to emdebian, or from the
emdebian repository for an existing emdebian package); puts
these in tarballs, and runs dpkg-source -x to put the correct
content in package1/, and leaves a copy of the Debian tree in
either tarballs/ or build-area/
- runs svn checkout to download the emdebian patch if it exists,
and then applies it to the working package1/ (moving
debian/changelog to debian/changelog.Debian and the emdeb
changelog to debian/changelog)
At this point, the package1/ working directory can be used and
edited, and test builds can be done in this working directory.
(2) Update SVN repository with current patch
Script which:
- runs debclean first of all (to remove cruft)
- does a diff between the Debian version of the package and the
emdebian one (doesn't even need to bother with interdiff)
- places the diff in emdeb-patches/package1 (either as a single
patch file or as multiple diff files, as discussed)
- checks in the changes to SVN
(3) Update working directory with current SVN version
This one's a bit harder, as there may be conflicts. My proposal
is this:
Script which start in the same way as in (2):
- does a diff between the Debian version of the package and the
emdebian one
- places the diff in emdeb-patches/package1 (either as a single
patch file or as multiple diff files, as discussed)
Then:
- checks OUT the current SVN version
- if this is successful, then applies the current set of patches
to the working tree, otherwise warn the user, highlight the
problems and ask them to fix them before going further
(4) Building a package
Building a local test one from the local tree is easy (debuild -us
-uc). But the equivalent of svn-buildpackage must do the
following:
- does a diff between the Debian version of the package and the
emdebian one
- places the diff in emdeb-patches/package1 (either as a single
patch file or as multiple diff files, as discussed)
- check that the patches are still up to date SVN-wise, otherwise
stop with an error
- if they're up-to-date, build an emdebian source tree in
build-area/, using the files in tarballs/ and the SVN version of
the emdebian patch, then run dpkg-buildpackage or whatever in
build-area/package1-1.2.3/
(5) Upgrading to a new Debian/upstream release
A script which is essentially a modification of the core of
uupdate:
- ensures that the working tree is up-to-date vis-a-vis SVN -
warns if not
Alternative 1:
- replaces the entire working tree with the new Debian version and
then tries to apply the emdebian patches to this new tree
Alternative 2:
- creates a patch from old Debian version to new Debian version
and tries to apply this to the working directory
Alternative 2 makes the huge assumption that binary files will not
change, otherwise diff will complain. And this is almost
certainly not likely to be the case. However, reading the diff is
useful for humans to check whether anything is likely to need
modifying emdeb-wise. Maybe do alternative 1 and also provide the
user with the output of debdiff?
I think that covers pretty much everything.
Note, incidentally, that this also means that Debian native packages
will produce Emdebian native packages (only a .tar.gz) and Debian
non-native packages will produce Emdebian non-native packages
(.orig.tar.gz and .diff.gz).
Users
-----
Well, that's easy: they just download the .orig.tar.gz and .diff.gz
(or .tar.gz) and build it just like an ordinary package.
Needs comments please (good and bad) before I start thinking about
coding any of this!
Julian
Reply to: