[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New Packager question again: can you point me to a not flawed package?

On Sun, 1 Jun 2008 15:12:14 -0500, Paul Johnson <pauljohn32@gmail.com> said: 

> 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.

> 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.


> 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.


        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.


My uncle Murray conquered Egypt in 53 B.C.  And I can prove it too!!
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: