Looking for advice: packaging a package with own modifications
Hi all, some days ago I got aware of the OpenBoard package, which is built in the openSUSE Education project. As my wife is a teacher, she was very happy that this was available for openSUSE Leap 15.2. I then wanted to switch from the latest release evrsion 1.5.4 to the current release candidate of 1.6.1. Additionally, I created a new tool to draw a coordinate system on the board. This is available in a fork on github at https://github.com/letsfindaway/OpenBoard. To package this work, I did the following: - I did an osc copypac to copy the Education:OpenBoard package to my home project at home:letsfindaway. - I updated the source with the zip archive downloaded from my project at github. - I updated one of the patches and removed two others, which have been upstreamed since 1.5.4. This works well, but I have a few questions: 1. Is copypac the right way? Is copypac the right way to create an own package which is quite similar to an existing one? How close is the binding to the original package after copypack? Are they independent or will the copy inherit any modifications to the original? 2. Best way to add own modifications First I thought I could just use the source zip from the original OpenBoard repository and add my modifications as a patch. However as my work contains a new image file in png format, I did not find a good way to put this file in a patch. Are there any recommendations how to do this? What about multiple Source specifiers in the spec file? Would they be approriate? How are they handled? 3. Version specification for such derived work Currently I'm just using 1.6.1 as the version specifier, which does not indicate that the package contains additional work. What would be the best way to express this in a version number? Finally I just want to thank the openSUSE people for providing such an awesome service as the OBS for such anybody!
Hi Martin, On 13.02.21 18:21, Martin Winter wrote:
Hi all,
some days ago I got aware of the OpenBoard package, which is built in the openSUSE Education project. As my wife is a teacher, she was very happy that this was available for openSUSE Leap 15.2. I then wanted to switch from the latest release evrsion 1.5.4 to the current release candidate of 1.6.1. Additionally, I created a new tool to draw a coordinate system on the board. This is available in a fork on github at https://github.com/letsfindaway/OpenBoard.
To package this work, I did the following:
- I did an osc copypac to copy the Education:OpenBoard package to my home project at home:letsfindaway. - I updated the source with the zip archive downloaded from my project at github. - I updated one of the patches and removed two others, which have been upstreamed since 1.5.4.
This works well, but I have a few questions:
1. Is copypac the right way?
It depends.
Is copypac the right way to create an own package which is quite similar to an existing one? How close is the binding to the original package after copypack? Are they independent or will the copy inherit any modifications to the original?
After copypac, the package is independent and has no connection to the "upstream" package in the Education project. If you want to have it connected, then you would need to linkpac or branch it.
2. Best way to add own modifications
First I thought I could just use the source zip from the original OpenBoard repository and add my modifications as a patch. However as my work contains a new image file in png format, I did not find a good way to put this file in a patch. Are there any recommendations how to do this? What about multiple Source specifiers in the spec file? Would they be approriate? How are they handled?
I'll state the obvious first: why don't you just get your modification into the upstream package, so that you do not need a modified package in your home repo? ;-) Now back to your question: I'd use the original tarball, add your modification as patch and add the new image as Source2: to the package.
3. Version specification for such derived work
Currently I'm just using 1.6.1 as the version specifier, which does not indicate that the package contains additional work. What would be the best way to express this in a version number?
Personally, I'd probably rename the package to "OpenBoard-Martin" :-) OTOH if this is just a feature addition and if you expect to have it merged upstream soon, then just adding the patch without further rename is also fine. Have fun, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am 13.02.21 um 18:54 schrieb Stefan Seyfried:
Hi Martin, Thanks for the fast response, Stefan!
On 13.02.21 18:21, Martin Winter wrote:
Hi all,
some days ago I got aware of the OpenBoard package, which is built in the openSUSE Education project. As my wife is a teacher, she was very happy that this was available for openSUSE Leap 15.2. I then wanted to switch from the latest release evrsion 1.5.4 to the current release candidate of 1.6.1. Additionally, I created a new tool to draw a coordinate system on the board. This is available in a fork on github at https://github.com/letsfindaway/OpenBoard.
To package this work, I did the following:
- I did an osc copypac to copy the Education:OpenBoard package to my home project at home:letsfindaway. - I updated the source with the zip archive downloaded from my project at github. - I updated one of the patches and removed two others, which have been upstreamed since 1.5.4.
This works well, but I have a few questions:
1. Is copypac the right way?
It depends.
Is copypac the right way to create an own package which is quite similar to an existing one? How close is the binding to the original package after copypack? Are they independent or will the copy inherit any modifications to the original?
After copypac, the package is independent and has no connection to the "upstream" package in the Education project.
If you want to have it connected, then you would need to linkpac or branch it. Ok, as I'm also switching to another version, copypac seems to be appropriate to me. I already know about "branch" but will read more documentation about "linkpac".
2. Best way to add own modifications
First I thought I could just use the source zip from the original OpenBoard repository and add my modifications as a patch. However as my work contains a new image file in png format, I did not find a good way to put this file in a patch. Are there any recommendations how to do this? What about multiple Source specifiers in the spec file? Would they be approriate? How are they handled?
I'll state the obvious first: why don't you just get your modification into the upstream package, so that you do not need a modified package in your home repo? ;-) I will definitely do this, once it has the quality for this step. Currently there are still sill some 'known issues' I want to resolve first. But in the meantime my wife already wants to have the new feature with the coordinate system! Now back to your question: I'd use the original tarball, add your modification as patch and add the new image as Source2: to the package. Ok, I will try that. Also as tarball with the same directory structure? Are all the Sources just unpacked to the same location during build?
3. Version specification for such derived work
Currently I'm just using 1.6.1 as the version specifier, which does not indicate that the package contains additional work. What would be the best way to express this in a version number?
Personally, I'd probably rename the package to "OpenBoard-Martin" :-) OTOH if this is just a feature addition and if you expect to have it merged upstream soon, then just adding the patch without further rename is also fine. Yes, it is just a feature addition and not a fork. At least I hope to have it merged upstream some day (soon? Let's see!). Probably I will append some indicator to the version. Have fun,
I definitely have! Martin
Hi Stefan, following your advice I now did some updates: Am 13.02.21 um 19:39 schrieb Martin Winter:
Am 13.02.21 um 18:54 schrieb Stefan Seyfried:
Hi Martin, Thanks for the fast response, Stefan!
On 13.02.21 18:21, Martin Winter wrote: 2. Best way to add own modifications
First I thought I could just use the source zip from the original OpenBoard repository and add my modifications as a patch. However as my work contains a new image file in png format, I did not find a good way to put this file in a patch. Are there any recommendations how to do this? What about multiple Source specifiers in the spec file? Would they be approriate? How are they handled?
Now back to your question: I'd use the original tarball, add your modification as patch and add the new image as Source2: to the package. Ok, I will try that. Also as tarball with the same directory structure? Are all the Sources just unpacked to the same location during build?
My spec file now is as follows: ... Source0: OpenBoard-dev-qt5.1x.zip Source1: OpenBoard-tool-axes.tgz ... %setup -q -n OpenBoard-dev-qt5.1x %setup -a 1 -T -D -n OpenBoard-dev-qt5.1x ... This works, but I don't know exactly why ;) I found the following documentation of the %setup macro: https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html-sin... In the first setup command, I'm using the -n OpenBoard-dev-qt1.5x option, because the tarball downloaded from github contains this directory as the top level directory. The tar archive specified for Source1 does not contain that top level directory. It starts one level below. I therefore added the -a option to tell setup to unpack the archive **after** changing to the named directory. I added the "1" to refer to Source1, ok? I'm using -D to avoid that this directory is cleaned before unpacking. But why the hell do I have to specify the -T? The documentation says: "-T Disable the automatic unpacking of the archives." What does this mean? If I omit that option, then a second attempt to unpack the Source0 (!) is made, which fails. So it seems that I did not really understand what -T means. Or did not really understand the %setup macro at all. I was also unable to add the file "as is", i.e. not as part of an archive. Did I miss something or is it assumed that I always pack my source files into some sort of archive? I first thought -T would exactly do this. But this seems not to be the case.
3. Version specification for such derived work
Currently I'm just using 1.6.1 as the version specifier, which does not indicate that the package contains additional work. What would be the best way to express this in a version number?
Personally, I'd probably rename the package to "OpenBoard-Martin" :-) OTOH if this is just a feature addition and if you expect to have it merged upstream soon, then just adding the patch without further rename is also fine. Yes, it is just a feature addition and not a fork. At least I hope to have it merged upstream some day (soon? Let's see!). Probably I will append some indicator to the version.
The version is now 1.6.1rc+axes. 1.6.1rc is what OpenBoard is using in their qmake project file. I append an indicator for my extension. It seems that a "-" is not allowed in version specifiers, so I'm using a "+". Thanks for your help! Martin
On Sunday 2021-02-14 14:22, Martin Winter wrote:
Source0: OpenBoard-dev-qt5.1x.zip Source1: OpenBoard-tool-axes.tgz ...
%setup -q -n OpenBoard-dev-qt5.1x %setup -a 1 -T -D -n OpenBoard-dev-qt5.1x
The tar archive specified for Source1 does not contain that top level directory. It starts one level below. I therefore added the -a option to tell setup to unpack the archive **after** changing to the named directory. I added the "1" to refer to Source1, ok? I'm using -D to avoid that this directory is cleaned before unpacking. But why the hell do I have to specify the -T? The documentation says: "-T Disable the automatic unpacking of the archives." What does this mean?
%setup always unpacks source0. unless you use -T... so you've overcomplicated it already. One setup can unpack everything. Just %autosetup -a1 -n OpenBoard-dev-qt5.1x
Hello, Am Sonntag, 14. Februar 2021, 14:22:58 CET schrieb Martin Winter:
I was also unable to add the file "as is", i.e. not as part of an archive. Did I miss something or is it assumed that I always pack my source files into some sort of archive? I first thought -T would exactly do this. But this seems not to be the case.
You can reference a source file as %{S:<number>}. For example this installs the Source2: file as apache config: install -m 0644 %{S:2} %{buildroot}/etc/apache2/conf.d/%{name}.conf Regards, Christian Boltz -- | Yes, I know. But there are even conjobs running as user games? Sometimes when cron is bored he starts playing games, didn't you know? ;-) [Aschwin Marsman and Robert Schiele in opensuse]
On Samstag, 13. Februar 2021, 18:21:36 CET Martin Winter wrote:
Hi all,
some days ago I got aware of the OpenBoard package, which is built in the openSUSE Education project. As my wife is a teacher, she was very happy that this was available for openSUSE Leap 15.2. I then wanted to switch from the latest release evrsion 1.5.4 to the current release candidate of 1.6.1. Additionally, I created a new tool to draw a coordinate system on the board. This is available in a fork on github at https://github.com/letsfindaway/OpenBoard.
To package this work, I did the following:
- I did an osc copypac to copy the Education:OpenBoard package to my home project at home:letsfindaway. - I updated the source with the zip archive downloaded from my project at github. - I updated one of the patches and removed two others, which have been upstreamed since 1.5.4.
This works well, but I have a few questions:
1. Is copypac the right way?
Is copypac the right way to create an own package which is quite similar to an existing one? How close is the binding to the original package after copypack? Are they independent or will the copy inherit any modifications to the original?
osc branch since you do want usually following the other project with their changes. And you could even submit them back, if they make sense for others (osc sr).
2. Best way to add own modifications
First I thought I could just use the source zip from the original OpenBoard repository and add my modifications as a patch. However as my work contains a new image file in png format, I did not find a good way to put this file in a patch. Are there any recommendations how to do this? What about multiple Source specifiers in the spec file? Would they be approriate? How are they handled?
3. Version specification for such derived work
Currently I'm just using 1.6.1 as the version specifier, which does not indicate that the package contains additional work. What would be the best way to express this in a version number?
Finally I just want to thank the openSUSE people for providing such an awesome service as the OBS for such anybody!
-- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
participants (5)
-
Adrian Schröter -
Christian Boltz -
Jan Engelhardt -
Martin Winter -
Stefan Seyfried