Re: New Packager question again: can you point me to a not flawed package?
On Sun, 1 Jun 2008 09:41:20 +0300, George Danchev <danchev@spnet.net> said:
> On Sunday 01 June 2008, Manoj Srivastava wrote:
>> On Sat, 31 May 2008 15:19:02 -0500, Paul Johnson
>> <pauljohn32@gmail.com>
> said:
>> > You may recall I was the one who asked yesterday "Why do you
>> > encourage packagers to open the source code and fool around?" I
>> > got answers which indicate that the source code generally should
>> > not be changed directly, and all changes should either be in
>> > patches that are stored in the debian/patches directory or in the
>> > other configuration files like "rules". I say "Yes, I agree" I am
>> > used to that from RPM building. I think you should force people to
>> > prove they can build packages by applying patches to an original,
>> > untouched tarball or putting details in a debian directory.
>>
>> 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.
> There should be ways to use both, since you depreciate your diff.gz
> and it turns to be a useless scratch of bits. Then, again why have
> diff.gz at all when it is not credible enough ?
Credible \Cred"i*ble\ (kr[e^]d"[i^]*b'l), a. [L. credibilis, fr.
credere. See {Creed}.]
Capable of being credited or believed; worthy of belief;
entitled to confidence; trustworthy.
I find the diff.gz as credible as anything else. Why would it be
less trustworthy?
In any case, as development proceeds, tools change. patch and
diff were great, once upon a time, just like programming in raw
Hex was still in vogue when I started programming.
>> 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
> Using a modern SCM is wonderful, but please, get back to the ground,
I don't think that using modern SCM's is crazy (if not being on
the ground has the connotations I think it has).
> and think of the possible use cases with what Debian has officially
> released, and if that is what warns a certain level of
> unification. There are users (let's say within restricted areas) who
> can't access random DD repos at will, but rely solely on diff.gz
> supplied by released source CD/DVD media. Please note that development
> history of changes is not of any help here, but what exactly has been
> applied (as logically separated changes) to a particular upstream
> version being released.
People who want to actually follow development would need some
net access -- or, with the 3.0 (git) format, have their topic branches
on their DVD. Realistically speaking, do you have any numbers on such
users who must rely on DVD's and can't get someone to burn a DVD for
them?
There is a tradeoff. There is correctness of the package , which
is eased by using topic branches (at least, for me), which trumps the
use cases you are talking about. Now, in cases where the branches do
not overlap, there can be a simple conversion to a stacked patch
format; and I'll have no objection to using a tool that can do the
conversion (at the expense of source package size bloat).
I do plan on using divergence bugs, as soon as we have the
summary post for a bug implemented, or sooner if I can manage it.
manoj
--
In a consumer society there are inevitably two kinds of slaves: the
prisoners of addiction and the prisoners of envy.
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: