[Starlingx-discuss] MultiOS: why not to place our Spec files in git directly
Hello, as OBS allows to read the spec files from the git repo, would it not be a great idea to extract it from there directly ? It would allow to get get the same review process allocated to that critical files. See example here: https://build.opensuse.org/package/view_file/OBS:Server:2.10/obs-server/_ser... Thoughts ? -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre
On 9/4/19 2:36 AM, Dominig ar Foll (Intel Open Source) wrote:
Hello,
as OBS allows to read the spec files from the git repo, would it not be a great idea to extract it from there directly ? It would allow to get get the same review process allocated to that critical files. See example here:
https://build.opensuse.org/package/view_file/OBS:Server:2.10/obs-server/_ser...
Thoughts ?
So if I am understanding what your suggesting, we just maintain an _service file in OBS and the spec file then comes from the SCM bundle? What about the case that some package has patches? Or other SourceX: directives in the spec file do those need to be listed also, it seems like that might be the case. Sau!
On 04/09/2019 15:37, Saul Wold wrote:
On 9/4/19 2:36 AM, Dominig ar Foll (Intel Open Source) wrote:
Hello,
as OBS allows to read the spec files from the git repo, would it not be a great idea to extract it from there directly ?
So if I am understanding what your suggesting, we just maintain an _service file in OBS and the spec file then comes from the SCM bundle?
What about the case that some package has patches? Or other SourceX: directives in the spec file do those need to be listed also, it seems like that might be the case.
Saul, as we get the source file from the scm, any patches should be done in the scm directly, it's far easier to maintain changes in git than on individual patches files. the git command in OBS allows to point toward a given branch if needed. We can also download the patch file from the scm with the same tool as for the spec file. Would a patch file be the right solution to a given difference management. In short my proposal is to manage only the _service file in OBS and all the rest via git, in order to apply the same review process to all the the project. -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre
On 04/09/2019 15:37, Saul Wold wrote:
On 9/4/19 2:36 AM, Dominig ar Foll (Intel Open Source) wrote:
Hello,
as OBS allows to read the spec files from the git repo, would it not be a great idea to extract it from there directly ?
So if I am understanding what your suggesting, we just maintain an _service file in OBS and the spec file then comes from the SCM bundle?
What about the case that some package has patches? Or other SourceX: directives in the spec file do those need to be listed also, it seems like that might be the case.
Saul,
as we get the source file from the scm, any patches should be done in the scm directly, it's far easier to maintain changes in git than on individual patches files. For the most part this will be true, but there may be some config or
On 9/4/19 7:05 AM, Dominig ar Foll (Intel Open Source) wrote: scripts that are maintained specifically for CentOS or openSUSE.
the git command in OBS allows to point toward a given branch if needed. We can also download the patch file from the scm with the same tool as for the spec file. Would a patch file be the right solution to a given difference management.
Sounds like we can make it work beyond just patches.
In short my proposal is to manage only the _service file in OBS and all the rest via git, in order to apply the same review process to all the the project.
Agreed! I think there might be some details to work out in certain cases, but we should target for _service in OBS with *.spec, *.changes being maintained in Gerrit. Sau!
Hello, as we are in sync, the next step is to transfer all the OpenSUSE spec files on git (like already done for Centos). I have corrected the last errors and all packages at least build. So we are ready. As soon the spec files are all in git; I will modify the _services accordingly. -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre
participants (2)
-
Dominig ar Foll (Intel Open Source)
-
Saul Wold