Re: Forwarded: RFC: New source packaging format
From: Jim Pick <firstname.lastname@example.org>
> I've just repackaged hello using my new proposed source packaging
> scheme which does away with dpkg-source and uses just dpkg and
> standard .deb files instead.
Good try, but I think it falls short of the mark in a few ways.
Have you discussed this with Klee? He has ideas in the same direction.
It would be really nice for source packages to create a subdirectory of
the current directory rather than an absolute pathname. I would like to
extract all source packages in the current directory, and have a bunch of
named directories like hello_1.3.1-1 .
A big advantage of "debian/rules" or even "debian/Makefile" (if you think
"rules" is a bad name) is that the Debian files can be installed in
the upstream source package without making that package Debian-specific.
For this reason, I think you should go to "debian/Makefile" if you do
anything like this at all.
The Makefile is extracting the tar archive. I think in general when I
extract a source package I would like it to create a directory containing
the extracted source, rather than a directory containing more archives.
The latest dpkg-source does OK at this, except for the fact that it still
insists we rename the original source archive, which I think is a mistake.
> !!! A source depedency !!!
We need something that _builds_ the packages in dependency order,
not unpacks them in dependency order. This is especially important once
they have already been unpacked and we are building for the n-th time.
Your source dependencies also apply when removing the sources, a
restriction we don't really need and one that can be very problematical.
What I'd like would be the ability to install and unpack in any order,
but then something that would _build_ the packages in dependency order.
> The cool thing is that this package could also declare a dependency to
> a binary package (ie. say it needed debmake).
If I am not mistaken, _all_ source dependencies are actually binary
dependencies, because they need the source to be _built_and_installed_.
Debian does not presently know how to build the entire system with
uninstalled libraries and headers, and I'm not sure it should be taught
how to do that. Using the established control file is a good idea.
> # packages here (using dpkg). But a user can install the source
> # elsewhere using dpkg-deb --extract, and then call
> # make srcdebiandir=xxxx to override the source location.
Not pretty. That would extract to ./usr/src/src-hello-1.3/, when I
want ./src-hello-1.3 . Of course I really want hello-1.3-1/ and extracted
stuff under there.
Something else that is not pretty is what happens when you install one
of your source packages on top of another one. I think what would happen
is that it would remove the old archive, but leave the old files that were
extracted from the archive in place, including the stamps. The "unpack"
stamp may then be more recent than the new archive, since dpkg sets the
file date when extracting, and the unpack step may not happen, leaving the
poor user compiling the old source without knowing it. You could remove all
of the stamps in the postinst script, I guess. Even if the stamp problem
does not happen, the old extracted files have not been removed when
extracting the new package, and you may be stuck with files that have been
deleted in the more recent source. Maybe you should remove all old files in
the postinst, too.
Can you get your operating system fixed when you need it?
Linux - the supportable operating system. http://www.debian.org/support.html
Bruce Perens K6BP email@example.com NEW PHONE NUMBER: 510-620-3502
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
firstname.lastname@example.org . Trouble?
e-mail to email@example.com .