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.
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 <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: