An alternative to deb-make Re: deb-make
Manoj Srivastava <srivasta@datasync.com> writes:
> >>"Igor" == Igor Grobman <igor@vaca.net> writes:
> Igor> Why duplicate work? Can't you and Christoph agree on how
> Igor> debmake should be changed in order for it to become an official
> Igor> standard. I just don't see a point in creating two packages
> Igor> with the same functionality. I think that debmake is very good,
> Igor> and creating another variant would take a lot of time. Time
> Igor> that could be spent better in writing needed enhancements to
> Igor> debmake or dpkg maybe.
> Actually, there are a few others who may not be happy with the
> current implementation of debstd et al. I don't think this is a
> matter of two developers squaring off and coming up with policy
> decisions critical to the core of the distribution.
I, for one, find deb-make unusable for all but the most basic
packages. Its setup for multi-deb packages is an afterthought, for
instance---and this hits me quite hard, since I maintain a large
number of multi-deb packages.
In fact, I've been engineering a replacement, based on the
deficiencies I've found in deb-make. I've used this to build an
unreleased ncurses, as well as glibc-2.0.1 for the Alpha, something I
could never get deb-make to do in such a fashion that I felt I knew
what exactly was happening.
Which is not to say that deb-make doesn't have some virtue---right
after Ian released the new package spec I wrote a message about how I
though having a tool that would do many of the thing deb-make would do
would be useful.
> He's got you there, Ian. All the rest of us developers may not
> be self proclaimed experts, but some of us have had experience in the
> field as well, and may have relevant input.
Considering all the things that the "standard" tools with dpkg _don't_
make simple---I'm thinking about dealing with multi-deb package here
again---I think it is blatantly obvious that all the developers need
to have some input. While not everyone may see their favorite
feature make it into this tool, at least we can guarantee that nothing
important is made complicated.
> Please, people, stop this trend of developing packages behind
> closed doors; I for one would welcome a discussion of this issue
> again.
As I alluded to above, I've already worked a bit on a replacement for
deb-make.
I would be happy to submit this to the developer community as a
possible tool to be modified and codified---with the caveat that I
think we must spend some time desiging and re-designing features. I
don't think we'll end up with a good tool unless we actually implement
suggestions and measure the benefit---I feel strongly enough about
this that I'll even volunteer to do most of it. :-)
Here are some of the things that I considered when designing it (and I
can fax my original notes on this to anyone who wants to suggest it
wasn't _designed_):
* Basic foundation
Creating deb files consists mainly of making sure you have two
different sets of files in the right places---the debian files and the
program files.
Thus, the intent of any "package assembly tool" should be to give the
user a variety of simple, easily understood "transformations" (I've
been reading about DSSSL a lot lately, does it show) that help her
automate (and therefore presumably simplify) the process of getting
those files in the right place.
My package assembly tool can perform a number of operations on files,
using the entries in debian/control file as its "master list",
performing operations on the packages in order through the list.
* Debian Files
The debian files are of two primary types---all-deb files and
single-deb files.
In other words, some files, like debian/control, are used during the
construction of all deb files that come from this source package,
while other files, like substvars, are (or should be) specific to a
particular deb file.
One obvious way to make the job of managing the debian files easier is
to use the directory structure to separate nonspecific files from
specific files, and files specific to one package from those specific
to another.
Thus, my utility, and I think common sense, dictates a simple
structure:
debian/
package1/
package1-dev/
package-bin/
Files common to all outputs, including rules, control and no doubt
others that I don't remember, all sit in the /debian directory.
Other files, including conffiles, shlibs, etc, are put in the
subdirectory corresponding to the name of the deb file for which they
are intended.
The utility takes care of dropping these various files (including the
processed control file, etc) into the right place. It insures they
have the correct permissions.
* Program files
The program files, on the other hand, each belong to a particular deb
file.
Even the most versatile installation process is likely to not sync
exactly with the needs of the debian package creator. As a result, it
is necessary for the user to easily an clearly do arbitrary moves,
renames, symlinks and deletes on a given set of installed files.
Given that these operations would have to be implemented anyway, I
decided that my packager would require that the entire package be
installed in the temporary directory for the first package in the
control file, which I will call the "master directory". Each package
has each operation conducted on it before proceeding to the next
operation
The user may then specify on the command line the type and order of
operations to be undertaken, for instance the parameter
--files=move,rename,delete,copy would cause the tool to do those
operations in that order.
What exactly should be done for a given operation is determined by
files in the individual package directories mentioned above.
files.move consists of a list of files relative to the "master
directory" (including wildcards) that should be moved from the "master
directory" to the temporary directory of the current package, with
files.rename, files, delete and files.symlink doing similar things.
I have come to the conclusion that there may be a need to have the
ability to pull files from the main distribution directory as well,
but I am not yet convinced of this.
* Package assembly
Another difference between my tool and deb-make is that I chose to
implement the build directories for different packages in an
straightforward fashion---each package gets a properly named directory
under debian/tmp, so you have, to take from my above example,
debian/tmp/package1, debian/tmp/package1-dev, debian/tmp/package-bin.
I can copy documentation automatically to the directory of the "master
package", and create appropriate symlinks to that directory in the
rest of the packages.
The tool, like deb-make, will automatically find executables and run
dpkg-shlibdeps on them, though unlike deb-make, it recognizes that
dependencies are a per-package thing, and thus creates a separate
substvars file for each package.
* The future
There are still some features I would like to steal from deb-make for
this phase---automatic compression of documentation (with the option
to override, of course) would be nice. I don't do the init.d and
info-file and some of the other stuff that deb-make does. Some of it
I wouldn't want to do (I intensely dislike the fact that deb-make will
hack pre and postinst scripts for you without your say-so), but some
of it would be nice.
Although I currently use Perl routines for a lot of it, I still resort
to cp and mv for certain operations---I think that should be changed.
Better error handling, of course. It should be possible to supress or
enable single operations when finer-grained control is needed but you
don't want to have to do all the dirty work yourself.
Ultimately, I feel that this also has some measure of
credibility---I've got both ncurses and glibc packaged using this
tool, and the binary-dep: target in the makefiles consists of little
more than:
make prefix=$(tmpdir)/$(package)/usr
deb-files --files=move,copy,delete,symlink ChangeLog TODO
I think this makes a compelling argument that it does make things
simpler, even on large packages.
Mike.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: