Re: Breaks in lenny
Manoj Srivastava <srivasta@debian.org> writes:
> On Fri, 21 Dec 2007 16:24:02 -0800, Russ Allbery <rra@debian.org> said:
>> I need to be able to maintain a ton of small patches in an easily
>> separable form that often will never be merged upstream, while doing
>> the absolute minimum of work to pull those patches forward each time a
>> new upstream version is released and still keeping each change
>> separate. quilt does this perfectly. All explanations that I've seen
>> so far on how to do this with git or arch are more complicated and
>> slower than my workflow with quilt. With quilt, the typical upgrade
>> is:
>
>> * import new upstream source (done in the underlying VCS)
>> * quilt push -a
>> * repeat for each failing patch until no patches fail:
>> - if quilt says patch was applied upstream, quilt delete the patch
>> - otherwise, quilt push -f <patch>, resolve conflicts, quilt refresh
>> * quilt pop -a
>> * commit results
>
> Heh. Here is my work flow.
> * tla_load_dir (in the upstream branch)
> * arch_upgrade (might have to run again, if I had to deal with
> conflicts the first time)
>
> Done.
>
> Seems like much simpler than the quilt thingy.
windlord:~> which arch_upgrade
arch_upgrade: Command not found.
You realize this is kind of an unfair comparison, right? :) I was
comparing the native tools, not the native quilt tool against the
machinery and automation you've written on top of arch for yourself over
the years.
It may be that arch plus your tool set would be simpler, although it
sounds like arch plus your tool set is basically exactly my work flow with
quilt.
> Err, a patch requires me to think, and It can't just be compiled
> automatically, for each branch. This is subjective. I find patches
> far harder to deal with in practice than separate branches. I can
> inspect the code straight out, rather than have to mentally manipulate
> the code _and_ a patch. If I need a patch, the VCS can generate it, so
> I don't lose out there either.
Maybe some of it just amounts to being familiar with different tools and
being used to different ways of thinking about code. For all of this,
including the parts I snipped, I hear what you're saying, but your way
still seems more complex to me and I'm just not convinced.
Anyway, it's mostly irrelevant, because....
>> I'm continuing to object to adding wording to Policy that discourages
>> people from using patch systems such as quilt or dpatch -- that's
>> where this all started.
>
> Oh, I agree there. Policy should ever say things about what
> tools people can use (umm. I am tempted to ban vi and derivatives in
> policy ... nah).
*heh*.
> Policy should be able to specify that there should be a simple
> mechanism to get to the sources that will be compiled, preferably
> without having to trust code that needs to be run as privileged users
> or is different from what will be run during the build process.
>
> So, while we might not want policy to say that people should not
> use quilt; we might want to be able to say that when I do dpkg -x
> *.dsc; what I get is what is gonna be compiled.
Well, if you say that, you're basically discouraging quilt, because that's
not how quilt works. The default state with quilt needs to be with
patches unapplied, not with patches applied. Otherwise, if you want to
use quilt rather than ignore its existence, you'll very quickly get your
tree into an inconsistent state. If you ship the Debian source package
with all the patches already applied, modifications made in that state are
modifications to the top patch, which is almost never what you want.
There are a bunch of other patch systems that work this way as well. I'd
rather deal with them by having some sort of debian/rules target that puts
the source in a state that people want, as was the original suggestion,
than to try to tell people not to use them in their most reliable mode.
As I said back at the start of this, one advantage of shipping a DVCS
repository is that it better supports this model of immediately starting
to modify things. Although I'll point out that if you want to actually
*use* the DVCS, you still don't want to do that, because you'll be editing
things in the wrong branch. You still want to create a branch first. So
the degree to which it better supports this model is somewhat dubious; as
with quilt, it only really supports it if you're willing to ignore the
workflow and put the tree into a weird state.
Anyway, the security team and the release team, however grudgingly, seem
to be willing to deal with quilt (and dpatch). I really don't think it
improves Debian to discourage the way in which quilt and dpatch are
already being used in the project. The only real improvement would come
from having everyone adopt the same set of tools (such as Ubuntu
standardizing on bzr) so that we always know what to expect. If we all
end up loving git, maybe that will happen, but I don't think we're there
yet.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: