bruce@pixar.com (Bruce Perens) writes: > 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. Klee hasn't told me any detail about what he plans on doing, unfortunately. The whole complete concept only came to me about 11:30 this morning, and I had hello repackaged 2 hours later. So I really haven't consulted with anyone yet. (That's why I phrased it as an RFC) > 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 . You could write a little 3 line script that does a dpkg-deb --extract to a temp directory, and does a 'mv /usr/src/debian/* .' (pretty simple, huh?) > 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. I don't think that Debian stuff should go upstream. Perhaps the upstream automake could be outfitted with some additional smarts (particularily in regards to policy items like copyrights or menu) and that would do everything we need upstream. Then a program such as debmake or debhelper would be able to create the Debian package completely with no maintainer intervention. > 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. You mean when you install the source package with dpkg, right? You are correct, the stuff doesn't get unpacked automatically. I think that's a good thing -- why waste disk space if you aren't currently involved in the process of building a package? > > !!! 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. I have an easy solution for this - make a modified dpkg that understands a "pseudo-package" that doesn't really exist - but when you install it with dpkg, dpkg will compile it from sources. That way, all we have to do is generate "pseudo-package" descriptions for all the binary debs we want, and invoke dpkg, and it will do everything in the right order. (Well, hopefully - maybe Manoj's pkgorder would help) Seems like a pretty quick hack to me, although I am uncomfortable with the inards of dpkg. Actually, this technique would also work great for handling generating other things from source at install time -- like dvi files from texinfo, HTML docs, PS Letter vs. A4 docs, etc. > Your source dependencies also apply when removing the sources, a > restriction we don't really need and one that can be very problematical. How so? If you don't like the dependencies, just use "dpkg --purge --force-depends". > > 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_. Not really, the debian source package might require uncompiled source or header files from other (upstream) source packages. > > # 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. I mentioned above that this could be solved with a simple script. > 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. This is only a problem in the rare situation where you upgrade a source package while in the middle of building a package. I doubt that it is going to be a common problem. Even so, a simple way around it would be to declare a dependency for the unpack rule in the Makefile to /var/lib/dpkg/info/<packagename>. I think that's probably overkill though and isn't terribly helpful for people who extracted the source using dpkg-deb --extract into a non-standard location. Cheers, - Jim
Attachment:
pgpqOV0jVvi0o.pgp
Description: PGP signature