| Summary: | devtool: improve handling for recipes that point to local source next to recipe | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Paul Eggleton <bluelightning> |
| Component: | devtools / tool chain | Assignee: | Markus Lehtonen <markus.lehtonen> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | meta.mr.watcher, meta.watcher |
| Version: | 1.8 | ||
| Target Milestone: | 2.0 | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Paul Eggleton
2015-04-13 14:32:36 UTC
Devtool should somehow make a difference between upstream sources (unpacked from an archive or cloned SCM etc) and "packaging" files, i.e. the local files under the layer directory. I'm not sure if devtool should even work with packages like makedevs as the files can be conveniently modified directly in the layer dir, anyway(?) If we support this, we should also support "extracting" the local files to the srctree (and "updating" back to layer dir) for packages which have both an upstream source and local files, like udev. What do you think? I'm unsure as to what to do for recipes where you have a mixture of upstream source and some local files - the question would be where should those files appear once extracted given that it still has to work when you do 'devtool modify' without -x and supply your own "pristine" source tree that doesn't have those files. (It could be that we just fall back to fetching them from their original location, which shouldn't be too hard.) At the moment it appears it does mostly work for recipes like makedevs, it just needs some fine-tuning. If practical I'd like to err on the side of having devtool work for as many recipes as possible even if in some cases you're only gaining the benefit of having the same workflow working and not much else. AFAIU, there are two packages in this regard:
1. S=${WORKDIR} (e.g. makedevs.)
2. Other packages (e.g. udev)
For #1 we could just ignore/remove patches (.patch and .diff files) and not commit them into srctree. With this modification it should be fairly consistent and usable.
#2 is bit more complicated. Somehow it would be nice to be able to modify the local files in the srctree in this case, too (like #1). Not least for the sake of consistency, IMO. Would it be feasible to put the local files into a subdir in the srctree ('meta', or 'localfiles' or whatever) and the trick the fetcher to fetch them from there?
I'm also wondering what to do when source files are modified (i.e. makedevs.c in case of makedevs) and update-recipe is run. Should we just create a patch which is what devtool currently does? Or update the original in the layer directory? The second one is hard to accomplish because we run git format-patch to generate patches and there is no way (that I know of) to exclude files/patches. We need to run format-patch anyway because some files are handled as patches. Makedevs is a tricky (and good) example because 'COPYING' is created/modified as a patch but 'makedevs.c' is a plain source file in the layer meta data. What assumptions can we make about the git version for users using devtool? I ask because git v1.9.0 added a nice feature called "negative pathspecs" which could do exactly what I'd want. I.e. something like: $ git format-patch -- . ':!makedevs.c' for excluding changes to makedevs.c from the patches. Well, if we are applying changes back to the recipe then I would have thought we would just replace the .c file. As far as git version is concerned, our current minimum is 1.7.8 so that might prevent us relying on that option... Ok, bad luck with the git version. I try to cook up something. So, the logic for changes would be something like: 1. If the file already exists in recipe space -> update the original source 2. Otherwise (e.g. new files, archived files etc) upload a patch |