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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
