Re: New Packager question again: can you point me to a not flawed package?
On Sun, Jun 1, 2008 at 1:06 AM, Manoj Srivastava <srivasta@debian.org> wrote:
> On Sat, 31 May 2008 15:19:02 -0500, Paul Johnson <pauljohn32@gmail.com> said:
>
>
> Err, I don't think even half of my packages follow those
> guidelines. I fall in the group of people who use a modern SCM for
> development, and not a stacked patch set. I am not going to presume by
> telling you that either approach is inferior, though I certain have an
> opinion.
>
> I do have a emacs package you can look at for details, if you
> wish: http://git.debian.org/git/users/srivasta/debian/vm.git
>
> manoj
> --
I think we are talking past each other.
By asking for patches, I don't mean to address the people who write
code and declare "release versions" and make available tarballs.
Those people are, of course, free to make whatever changes they want
in their programs. They can use CVS, GIT, or whatever. Presumably,
those people maintain change logs. People who want to develop on a
package can get that same version control system and join in the
hacking.
I mean to address the people who turn those "release tarballs" into
Debian packages. The people I'm working with don't care to make
Debian packages, they develop programs that they can run on whatever
system, and they leave it up to Redhat, Debian, Mandriva users to do
what they need to in order to put the package in to the distribution.
That process is the one that we were discussing before. That's where
I need "best practices" and why I thought/think it is a really bad
idea that Debian packaging process requires one to untar a tarball and
write stuff inside it. Given that system, we need to protect the
integrity of software.
I think the point we were agreeing on yesterday was
1. If no substantive change is needed in the release version of
software for inclusion in Debian, then the only changes revealed in
diff.gz should be in the debian subdirectory.
2. Any substantive changes against the release version of the tarball
should be in patches in the patch directory.
The usual situation in which I find myself is that I'm not the
developer and don't declare release versions, I take a tarball from
somebody. That's what I'm trying to do now.
The developers who give us that tarball don't want me mucking about in
their source code, changing whatever I want. If I have to make
changes, they want to see patches that are separate and easily
identifiable in purpose. If they agree with the changes I recommend,
they may fix upstream.
So in my usual process of package development, I'd have the original
source, a modified source tree, I'd run "diff -rc orig source >
whatever.patch" after making specific changes and I'd collect those
up.
Here are some example. GCC's version of objective C has become more
strict in its interpretation of methods and return arguments. It
generates warnings and errors where it did not do so in the past. To
fix those, I have to go in the source and tighten up some things.
Those changes need to be in a separate patch in order to allow the
developer to approve the changes I make.
Here's another example. We've been using a graph library a long time,
at least 12 years. The developer seems to go missing for months at a
time. We don't make changes in his source, rather we collect up
patches representing changes we think are needed, and we use the
software. He's uninterested in packaging for Debian, Redhat, or
whatnot. If we collected up all those little changes into one massive
diff.gz, there's no way he'd have the patience to wade through it.
If the person who is doing the actual software development makes a
Debian package, I say hooray, that person can do whatever the hell
she/he wants inside the code. That is what developers do. Packagers,
on the other hand, should not make unaccountable changes.
Sincerely,
PJ
--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
Reply to: