On Sun, 1 Jun 2008 15:12:14 -0500, Paul Johnson <[EMAIL PROTECTED]> said:
> 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. > I mean to address the people who turn those "release tarballs" into > Debian packages. You seem to think the world is divided between coders and glorified packagers. I do not happen to see the free software community that produces distributions in these starkly distinct lines; I usually am involved in the development of the packages I maintain (or have been at some point in the past, and time dictates how active i am in upstream development) > 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 you will find different bet practices. I tend to try and create the best piece of software, that integrates well into Debian that I can. Sometimes it requires changing stuff outside of./debian; and some of these changes are not acceptable to the upstream author. > 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. Sure. > 2. Any substantive changes against the release version of the tarball > should be in patches in the patch directory. Nope. > 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. Sure. > The developers who give us that tarball don't want me mucking about in > their source code, changing whatever I want. Tough. I try to stick to free software, and people who develop free software do not do it in a vacuum, and they do not restrict what downstream do4es with the code. > 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. That is reasonable. git-format-patch, for my SCM, is designed specifically for that. I sed my upstreams these nicely formated seprate patches, updated to the latest release. > 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. Whatever floats your boat. I find that too much work, and not powerful enough, but hey, you are not me. > 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. I guess I am not a packager. Never wanted to be one, either. manoj -- My uncle Murray conquered Egypt in 53 B.C. And I can prove it too!! Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
