On Sun, Jun 1, 2008 at 1:06 AM, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > On Sat, 31 May 2008 15:19:02 -0500, Paul Johnson <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
