quiltpatch管理 - CSDN文库

patch

quilt

4星 · 超过85%的资源需积分: 34 137 浏览量更新于2023-07-10 评论收藏 180KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

How To Survive With Many Patches

Introduction to Quilt

∗

Andreas Gr¨unbacher, SuSE Labs

agruen@suse.de

June 12, 2005

Abstract

After lo oking at diﬀerent strategies for dealing with software packages

that consist of a base software package on top of which a number of patches

are applied, this document introduces the script collection quilt, which was

speciﬁcally written to help deal with multiple patches and common patch

management tasks.

1 Introduction

In the old days, vendor speciﬁc software packages in the open source world

consisted of a ﬁle with the oﬃcial version of the software, plus a patch ﬁle

with the additional changes needed to adapt the package to speciﬁc needs. The

oﬃcial software package was usually contained in a package.tar.gz ﬁle, while

the patch was found in package.diﬀ. Instead of modifying the oﬃcial package

sources, local changes were kept separate. When building the software package,

the tar archive was extracted, and the patch was applied.

Over time, the patch ﬁle ended up containing several independent changes.

Of those changes, some were integrated into later versions of the software, while

other add-ons or adaptations remain external. Whenever a new oﬃcial version

was integrated, the patch needed to be revised: changes that were already

integrated in the oﬃcial version needed to be split from changes that were not.

A big improvement was to allow multiple patches in a vendor package, and

this is also how patches are handled today: a number of patches is applied

on top of each other. Each patch usually c onsists of a logically related set

of changes. When some patches get integrated upstream, those patches can

simply be removed from the vendor speciﬁc package. The remaining patches

∗

Quilt is a GPL licensed project hosted on GNU Savannah. Some ideas for this document

were taken from docco.txt in Andrew Morton’s patch management scripts package [1]. The

text in the examples was taken from A Midsummer Night’s Dream by William Shakespeare.

frequently continue to apply cleanly. Some of the remaining patches may have

to be maintained across a range of upstream versions because they are too

speciﬁc for the upstream software package, etc. These patches often get out of

sync, and need to be updated.

For the majority of packages, the numb e r of patches remains relatively low,

so maintaining those patches without tools is feasible. A number of packages

have dozens of patches, however. At the extreme end is the kernel source package

(kernel-source-2.4.x ) with more than 1 000 patches. The diﬃculty of managing

such a vast number of patches without tools can easily be imagined.

This document discusses diﬀerent strategies of dealing with large sets of

patches. Patches are usually generated by the diﬀ utility, and applied with the

patch utility. Diﬀerent patch ﬁle formats are deﬁned as part of the speciﬁcation

of the diﬀ utility in POSIX.1 [3]. The most commonly used format today,

uniﬁed diﬀ, is not covered by POSIX.1, however. A good description of patch

ﬁle formats is found in the GNU diﬀ info pages [4].

The question we try to answer in this document is how patches are best kept

up to date in face of changes both to the upstream software package, and to

the patches that precede them. After looking at some existing approaches, a

collection of patch management scripts known as quilt is describ e d [2], starting

with basic concepts, and progressing towards more advanced tasks.

2 Existing Approaches

The minimal solution for updating a patch is to apply all preceding patches.

Then, a copy of the resulting source tree is created.

The next patch in the

sequence of patches (which is the one to be updated) is applied to only one of

these source trees. This source tree is then modiﬁed until it reﬂects the desired

result. The new version of the patch is distilled by comparing the two source

trees with diﬀ, and writing the result into a ﬁle.

This simple approach is rather error prone, and leaves much to be desired.

Several people have independently written scripts that automate and improve

upon this process.

A version control system like CVS or RCS may be a reasonable alternative

in some cases. The version control system is brought in the state of the working

tree with a number of patches applied. Then the next patch is applied. After

the working tree is updated as required, a diﬀ between the repository copy and

the working tree is created (with cvs diﬀ, e tc). In this scenario the version

control system is used to store and compare against the old repository version

only. The full version control overhead is paid, while only a small fraction of its

functionality is needed. Switching between diﬀerent patches is not simpliﬁed.

The two copies can also be hard-linked with each o ther , which signiﬁcantly speeds up

both the copying and the ﬁnal “diﬃng”. If hard links are used, care must be taken that the

tools used to update one copy of the source tree will create new ﬁles, and will not overwrite

shared ﬁles. Editors like emacs and vi, and utilities like patch, support this.

One of the most advanced approaches is Andrew Morton’s patch manage-

ment scripts [1]. The author of this document found that none of the available

solutions would scale up to the speciﬁc requirements of the SUSE kernel-source

package, and started to improve Andrew Morton’s scripts until they became

what they are now [2].

3 Quilt: Basic Concepts and Operation

The remainder of this document discusses the script collection quilt.

With quilt, all work occurs within a single directory tree. Since version 0.30,

commands can be invoked from anywhere within the source tree. Commands

are of the form “quilt cmd,” similar to CVS commands. They can be abbreviated

as long as the speciﬁed part of the command is unique. All commands print

some help text with “quilt cmd -h.”

Quilt manages a stack of patches. Patches are applied incrementally on top

of the base tree plus all preceding patches. They can be pushed on top of the

stack (quilt push), and popped oﬀ the stack (quilt pop). Commands are available

for querying the contents of the series ﬁle (quilt series, see below), the contents

of the stack (quilt applied, quilt previous, quilt top), and the patches that are not

applied at a particular moment (quilt next, quilt unapplied). By default, mos t

commands apply to the topmost patch on the stack.

When ﬁles in the working directory are changed, those changes become part

of the working state of the topmost patch, provided that those ﬁles are part of

the patch. Files that are not part of a patch must be added before modifying

them so that quilt is aware of the original versions of the ﬁles. The quilt refresh

command regenerates a patch. After the refresh, the patch and the working

state are the same.

Patch ﬁles are located in the patches sub-directory of the source tree (se e

Figure 1). The QUILT

PATCHES environment variable can be used to override

this location. The patches directory may contain sub-directories. patches may

also be a symbolic link instead of a directory.

A ﬁle called series contains a list of patch ﬁle names that deﬁnes the order in

which patches are applied. Unless there are means by which series ﬁles can be

generated automatically (see Section 5.8), they are usually provided along with

a set of patches. In series, each patch ﬁle name is on a separate line. Patch ﬁles

are identiﬁed by pathnames that are relative to the patches directory; patches

may be in sub-directories below the patches directory. Lines in the series ﬁle

that start with a hash character (#) are ignored. When quilt adds, removes,

or renames patches, it automatically up dates the series ﬁle. Users of quilt can

modify series ﬁles while some patches are applied, as long as the applied patches

remain in their original order.

Diﬀerent series ﬁles can be used to assemble patches in diﬀerent ways, cor-

responding for example to diﬀerent development branches.

Before a patch is applied (or “pushed on the stack”), copies of all ﬁles the

剩余11页未读，继续阅读

wiliiamjunxiang

2014-03-21

这个大家可以使用一下，感觉挺不错的。

内核老工人

粉丝: 8
资源: 5

会员权益专享

quilt patch管理

评论1

会员权益专享

最新资源

quilt patch管理

评论1

Python-Quilt一个数据包管理器像管理代码那样管理数据

Quilt：一个数据包管理器，像管理代码那样管理数据-python

Quilt使用入门介绍.pdf

quilt卸载指定补丁

/bin/bash: quilt

linux源码打补丁命令

对0002-Modify-cam_board_rk3326.xml-for-JXH62-camera.patch处理可以如对0001-Add-JXH62-camera-driver.patch的处理一样，可以完全自动化，无需手动。

deb打包的三种方法

全球等经纬度投影，分辨率为0.25度，WRF模拟em_real中namelist.input配置样例

全球等经纬度投影，分辨率为0.25度，WRF模拟中namelist.wps和namelist.input配置样例

全球等经纬度投影，分辨率0.25度， wrf和wps配置样例

quilt-0.46

openwrt 制作patch

matlab 实现image quilt算法

quilt3‑3.5.0‑py3‑none‑any.whl

Quilt使用入门介绍.docx

quilt-0.48.tar.gz

会员权益专享

最新资源