This is a reply to comment #8.

> Quilt is not aware of dependencies beyond the order of the patches in the series file. "quilt graph" can be used to try and guess the dependencies, but its heuristics are very basic and it is not meant to be complete (and it can't be, really.) The user is supposed to know the dependencies, and to sequence the patches accordingly in the series file.

This is probably a different way to describe the same situation, but I would say that in the current situation, the "user" which runs quilt does not necessarily have to know dependencies. It is the developer which creates series files which has to know. I would say that Quilt is aware of dependencies, in a sense, but it is indeed not aware of the exact (minimal) dependencies of each patch.
 

> Your last example is utterly confusing. It looks pretty theoretical to me, almost academic, considering that "diff" and "patch" operate on a per-line basis, so consecutive changes on the same line must have a well-defined order by definition. Whether these changes depend on each other is irrelevant then, due to this technical limitation.

I intentionally used a trivial example which is indeed unlikely, but there are numerous similar cases. For example, starting from:
<span>Choose files</span>
... patch 1 may translate with:
<span>{tr}Choose files{/tr}</span>
... and patch 2 may bring to:
<div>{tr}Choose files{/tr}</div>

The corresponding patches could "conflict", as patch is not smart enough to apply 2 patches which would both be based on the original line.

So, either:
1. As I suggested, if patch #2 is based on the file modified by patch #1, it is declared as "artificially depending" on patch #1.
2. Quilt automatically figures out artificial dependencies between patches, which may turn out difficult.
3. Quilt tries applications and may report to users that the operation they requested failed.
 

> You are focusing on the dependency model, and this is indeed one thing that would have to be extended in quilt to support your scenario. However this is not the only problem, and probably not the most difficult one.
> For me, the real problem is that quilt was fundamentally designed around the idea that the set of applied patches always matches the beginning of the series file. As a matter of fact, we even have a check in place to stop any quilt operation except "pop" whenever this assumption is no longer true.
> This design decision has two implications:
> 1* We know that all patches below the top patch must be applied, and all patches above the top patch are not applied, always. This allows for code optimization in various places. To be able to apply the patches in arbitrary order, we would have to make the code slower and/or more complex.
> 2* The semantics of the quilt commands are clear. If suddenly it is possibly that the series file and the list of applied patches are unrelated, the meaning of several commands will become ambiguous. For example, would "quilt previous" return the patch before the top-most patch in the series file, or the patch that was applied right before the topmost patch? Would "quilt next" return the patch after the topmost patch in the series file, or the first unapplied patch in the series file? With the current model, it doesn't matter because the answer is the same. With your proposed model, the answer is no longer the same.

I agree that in addition to a dependency model, a new format to specify dependencies needs to be determined.

I basically agree with point 2, although the term "ambiguous" may be strong, and I suppose quilt next; would have to consider the suggested order, it cannot guess the actual installation order. For quilt previous; the manual can of course document what it does. Or an argument allowing to choose between the 2 possibilities can be added.
 

> So in order to implement your request, we would not only have to add support for explicit dependencies between patches. We would firstly have to redesign the quilt command set, and rewrite the underlying code. I can't see this happening, sorry. Too much work and too risky, only to solve what is essentially an organizational issue in your company really.

I would not say that this request is essentially to help with an organizational issue in my customer's organization.

First, I think there are legitimate reasons why server administrators and developers are kept separate. For example, if we developers create a bug which causes problems, we can't rush to deploy a fix hoping to cover our error without other teams noticing. I am sure that many organizations work this way.

Second, there are simpler reasons why solving this problem would help us. For example, if I notice a new problem and try to identify which patch it comes from, I am likely going to want to remove a single patch at some point. If there are no patches which really depend on it, it would help to be able to remove it without removing other patches just because these come later in series.

Thinking about other projects, if Bob is a Debian user which develops Mozilla products, perhaps Bob will want to run a Firefox as close to Mozilla's as possible, and only apply the really necessary patches. But if some patches come late in series, Bob would have to modify series to unapply them, which may not be something Bob is confident enough to do.

I am confident that solving this would be beneficial to some degree for a large portion of users. But I absolutely agree that it needs important changes, which would take even more important work in a shell scripting context. I would certainly advise anyone planning to write a solution to first describe it and seek pre-approval from Quilt maintainers.

After more thought, I'd suggest considering 2 types of "dependencies" between patches first.diff and second.diff ...

A first type would be a real dependency. If the change performed by first.diff is missing, applying second.diff may work, but the resulting application will be broken.

The second type would be an "artificial" dependency. If the change performed by first.diff is missing, quilt/patch will refuse to apply second.diff, because both modify the same lines. But if second.diff was rewritten so it doesn't contain the initial lines as modified by first.diff, it could be applied without breaking the resulting application.

An example of the second type would be if the program writes the message "Helo Word". first.diff would add the missing "l", and second.diff would add the missing "l". second.diff could be considered "dependent" on first.diff, but in reality, any fix can be made first.

Thank you Martin,
The complexity of our context is bureaucratic. I am part of the software team, but I have no control over the business team, which determines whether a change can be deployed or not. We also have an infrastructure team which would be the one applying patches to the production instance. The infrastructure team knows nothing about our software, nor even our technologies. We don't mind the infrastructure team running quilt push/pop, but we don't want them to determine (effectively) patch file dependencies by crafting series files themselves. What we want is to provide a flexible set of files. Then, if the business team tells the infrastructure team to apply some patch, the infrastructure team can do so without modifying files nor requiring the software team to intervene.

Hello,

your proposal would be rather complex to develop in a generic way, regardless of the programming language. I fail to see how your usecase, that is really simple compared to other settings in which quilt is successfully used (kernel both upstream and in all distribution, any software in debian and derivatives, etc), is really mandating such a difficulty.

Given that most of your patches do not depend on each other, why don't you just throw their names in the serie file?

If you need something more complex, I'm sure you can generate the serie file on your side using a specific formatting of the header. Simply add a Depends-on: field in the DEP3 [1], develop a simple tool in the programming language of your choice that parses these fields in all patches to generate the serie file before calling quilt, and you're set.

This is the good thing about the current implementation of quilt. Its format is so simple that it's really easy to extend its tooling on your side. For example in Debian, quilt is used by maintainer to modify the patches, but at build time, they get applied by dpkg directly without depending on quilt itself. Plus, the DEP3 standard allows a lot of additionnal tooling that quilt has no idea about.

Thanks for your feedback anyway -- my opinion is in no way definitive here.

Bye, Mt.

[1] http://dep.debian.net/deps/dep3/

I realize that solving this with software based on the shell command language would be challenging. If someone knows of similar software which may be more suitable for our use case, I would appreciate to know.