Re: How to cope with patches sanely (Was: State of the project - input needed)
Le Fri, Jan 25, 2008 at 12:51:40PM -0500, Joey Hess a écrit :
>
> Unless what you get when you run apt-get source is *not* the source that
> is in the end used to build the package, which is instead squirrled away
> in some arbitrary patch format somewhere under debian/. In this case,
> unlike in the vcs case, you have to figure out an arbitrary other tool
> to get the source.
Dear all, dear Joey,
[This is a long mail, I hope that there is not too much verbillage in
it. I encourage other participants to this interesting thread to take
the opportunity of this week-end to take their time and write condensed
answers instead of discussion-style answers.]
I think that one of the driving forces for the adoption of patch
systems is that they give an opportunity to organise the information and
make it easier to review. Now it may be the wrong answer to the
question, but in the absense of a document explaining how to implement
an alternative method, I guess that things are not going to change
rapidly.
By storing multiple patches in debian/patches, we indicate to upstream,
users and devloppers which change has which effect. This is not possible
in the .diff.gz, except by verbosely paraphrasing the patches
themselves, writing in english that at line X, the change Y does Z.
(Comments in the code usually do not include reference to coordinated
changes in other locations in the source, whereas the juxtaposition of
the changes in a patch does.) Importantly, the debian/patches way
provides this information offline, as it is is part of the source
package. Also, having them as files in a directory allows to users and
developpers to easily inactivate them if needed.
I am so ignorant of git that I probably have missed if what you propose
allows to do this and better. Can you or somebody else give some
explanation at a beginner level? I also did not understand if the
proposed solution can work if upstream is not using a VCS at all, as we
do not want to duplicate hundreds of megaoctets of upstream sources.
Neither how it works in the case of repackaging.
Let me summarise the features I am talking about:
- Changes are grouped accorging to their goal.
- Easy way to swich the changes on/off.
- All the information is in the Debian source package.
- No upstream sources in the packaging team VCS.
As Andreas said in this thread and in ohters (about the Debian Menu
system for instance), we are eager to use the best solution if they are
established, documented and durable standards.
Of course, we are aware of the shortcommings of our approach, and this
thread made us understand them better:
- Just because there are patches in debian/patches does not say how to
use them.
- Patching a patched file is not convenient.
- After doing apt-get source, the unpatched sources are displayed, and
there is no instruction on how to review the patched sources.
Anyway, the situation is not that bad: it seems that only three systems
take the lion's share of patch management: dpatch, quilt, and cdbs. All
use the same directory, the two first manage their patches using the
only file in the directory that is not a patch, 00list or series, and
the last one just applies everything. Quilt and cdbs accept patches that
originate from the diff command. So for most uses, there is no need to
deeply understand the patch system to add or remove a patch, with the
major problem being apparently to generate patches for the dpatch system
(this is why I do not use it anymore).
Nevertheless, it is a bit scary to hear that one of the systems, quilt,
is not actively maintained. Does this mean that at any time the tool
could be removed and that we would have to migrate all our packages to
another system? Group maintainance of such core tools would definitely
help.
Debian has grown big, and information diffuses surprisingly slowly (who
knew about debcheckout before reading this thread ?). I am sure that we
(the Debian-Med packaging team) are not the only team that would like to
have some assurance that the packaging tools they use will have a
lifetime of a few releases. How about identifying the major components
and organising a certification system similar to the architecture
certification? I would be very happy to decide to use only certified
tools.
Have a nice week-end,
--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan
Reply to: