| Summary: | apply-patches.sh reorders patches given on the command line | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Christoph Schulz <develop> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | buildroot |
| Priority: | P5 | ||
| Version: | 2012.02 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: |
prevents reordering patches
prevents reordering patches (improved) |
||
Created attachment 4142 [details]
prevents reordering patches (improved)
According to some comments on the mailing list, here is an improved version of the patch. Expanded patterns are sorted but arguments to apply-patches.sh are not generally reordered. That means that apply-patches a z f* c given the patches "a c f1 f2 z" in the patch directory causes the patches to be processed as follows: a z f1 f2 c This should make apply-patches.sh conforming to both requirements (sorting of patches specified by a pattern and no reordering of arguments). What are the packages affected by this bug? Note that using the latest patch policy (see the new patch naming convention): http://buildroot.org/downloads/manual/manual.html#patch-policy After fixing the culprit patch filenames, this bug should not occurs anymore. So, it's better to fix the packages themselves. (In reply to comment #3) > What are the packages affected by this bug? > > Note that using the latest patch policy (see the new patch naming convention): > http://buildroot.org/downloads/manual/manual.html#patch-policy > > After fixing the culprit patch filenames, this bug should not occurs anymore. We have extended the uClibc buildroot by many additional packages which sometimes contain patches in debian/patches/. These patches are not ordered by name, rather there is a file debian/patches/series which contains the patches to be applied line by line. These are _not_ patches that lie in buildroot/package/<name>/. You should not assume that users of the uClibc buildroot only use packages that are contained therein. This is a mistake. Typically, the buildroot is extended by other self-made or customized packages in order to provide additional, target-specific functionality. In our case, we e.g. provide packages for the various ISDN-related tools coming with the isdnutils package. We take the isdnutils sources from Debian which distributes them in two archives: the original sources and separate patches, structured as described above. Best regards, Christoph If the path given to the apply-patches.sh script is a directory that contains a "series" file, then this series file is used to know the order in which patches should be applied. |
Created attachment 4052 [details] prevents reordering patches When support/scripts/apply-patches.sh is given an explicit list of patches instead of a template, they are sorted by name before being applied. This is bad as sometimes the order of patches is important, e.g. if one patch depends on another one. This happens e.g. when applying Debian patches whose order is explicitly described in the file debian/patches/series. The culprit is a "ls -d" which has to be changed to "ls -dU" in order to prevent sorting to take place. I have attached a corresponding patch.