Re: New source format and related issues...
Michael Alan Dorman writes ("New source format and related issues..."):
...
> I've looked at the docs, I've examined hello and dpkg, and I'll be
> damned if I can find any information that would allow me to actually
> reproduce the files that were uploaded to master, and assuming that
> dpkg was in fact build with the utilties it includes, this is
> annoying.
Both dpkg and hello were built with those utilities.
> My first problem stems from the simple fact that the new process of
> building a package isn't terribly well documented in the programmers
> manual---it devotes a whole sentence to saying "Look at
> dpkg-source(1)". Since I missed that sentence, I was baffled for a
> while.
I'll see what I can do about this.
> This was compounded by the fact that, since the 'source' target is
> still listed in the .PHONY target, when you do 'debian/rules source',
> you get "Nothing to do for target source", rather than "Don't know how
> to make source", or even better, "Source is an obsolete target, please
> use dpkg-source".
This will be fixed in the next hello package.
> Anyways, I finally figured out that I had to invoke dpkg-source. So I
> tried dpkg-source, and here's what I get:
>
> dpkg-source: building hello in hello_1.3.orig.tar.gz
> tar: Cowardly refusing to create an empty archive
> Try `tar --help' for more information.
> dpkg-source: failure: tar gave error exit status 2
>
> Since I had both appropriate hello-1.3 and hello-1.3.orig directories,
> I figured maybe I was doing something wrong in invoking dpkg-source,
> so I looked around a little more and found dpkg-buildpackage. After
> figuring out that it needs to be run from within the debian source
> directory, I ran it, and lo and behold, it has the same problem with
> dpkg-source that I do.
Well, all I can say is that it doesn't do this for me.
Can you send me, privately,
(a) what command line you're invoking dpkg-source with
(b) the output of `find -ls' in the directory where you're invoking
it ?
> So, I've got the tools, but I can't get them to work, and furthermore,
> most of them aren't even mentioned in the draft programmers manual
> that goes to great lengths to document the files and requirements and
> so forth, without ever really discussing the the tools, or how to use
> them.
The tools are documented in the manpage. Have you read the manpage ?
I'll try to put some less reference-oriented documentation in the
programmers' manual.
...
> Also, on the subject of our available examples: I think the
> debian/rules file in the hello source package makes at least 1 poor
> decisions in how certain things should be implemented---and given that
> prospective maintainers are often pointed in its direction, I think we
> should take care of these before immortalizing them.
If you send me good patches to hello I'll integrate and release them.
I'm not going to defer the release of the new source format because
the examples aren't ideal.
...
> It would also be nice if we could produce some simple tools that would
> help take care of some of the small administrative headaches
> automatically---say, a tool that would look through the debian
> directory and install all appropriate files into the DEBIAN directory,
> running them through any appropriate filters.
`cp' ?
> Another useful tool would go through the temporary directory structure
> and assign permissions and ownerships. Certains parts of the tree
> (*/bin, */man, you get the idea) would have defaults associated with
> them (0755, for */bin, 0644, for */man, root.root owning everything,
> etc). The package maintainer would then need only supply the program
> with a list of the exceptions (along with correct perms and
> ownership), and the rules file then could just execute _that_ command
> with su -c, since nothing else would need that access (well, the clean
> command might).
Feel free to write this command. I don't have time, I'm afraid.
> Now I know that there are always situations in which this just
> wouldn't work, and that's fine---there's nothing that stops a rules
> file from overriding parts of this when necessary. The important
> thing is that tools like this would make the creation of 90%+ package
> that much more automated, and most likely that much more free of the
> little bugs that clutter up the bug system.
Yes.
Ian.
Reply to: