Hello, In my institute we are selecting the operating system and Leap 42.1 is a strong candidate. In the selection process we are deeply analyzing the packaging and package management aspects. Currently we use openSUSE 11.1 and some custom GUI packaging and installation tools based on RPM. With the new OS we would like to follow the packaging good practices of the distribution. We have already tried building packages for the python projects, using the python setup.py bdist_rpm (based on distutils), but we also wanted to give a try to the "openSUSE:Packaging guidelines [1]. We mostly use Python and C++ projects, hosted on sourceforge/github or our local repositories. We do want to implement Continuous Delivery, so automatic packaging and deployment to the testing environment is crucial for us. Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. We have not found information on how to build locally packages apart of a link to the Fedora How to create RPM packages [3]. There is also a possibility to setup our private OBS system, but maybe it is too complicated solution for what we need right now. Could you provide us a guide on how to do packaging in the most compatible with the openSUSE standards way. Thanks a lot for your help! Zibi [1] https://en.opensuse.org/openSUSE:Packaging_guidelines [2] https://en.opensuse.org/Portal:Build_Service/Documentation [3] http://fedoraproject.org/wiki/How_to_create_an_RPM_package -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 2016-01-21 16:34, Zbigniew Reszela wrote:
In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public.
It's a misconception, fueled by misnomer. OBS (OpenBuildService) is the software which drives build.opensuse.org, the latter of which people incidentally also call OBS (openSUSE's build service). Not to mention that the guys from OBS (Openbroadcast studio) also regularly lose their way into the OBS IRC channel(s). So, OBS is also for private use. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
You can setup a private OBS instance and manage all your "internal" packages and packaging there for any of the supported distro's. In the past I ran a private OBS instance and had packages for a few openSUSE versions, SLES, RHEL/CentOS. You can link the private instance, package and or projects, against the public service for dependency handling, it's super flexible and will simplify packaging immensely. https://en.opensuse.org/openSUSE:Build_Service_private_instance -- Later, Darin On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Hello,
In my institute we are selecting the operating system and Leap 42.1 is a strong candidate.
In the selection process we are deeply analyzing the packaging and package management aspects. Currently we use openSUSE 11.1 and some custom GUI packaging and installation tools based on RPM. With the new OS we would like to follow the “packaging good practices” of the distribution. We have already tried building packages for the python projects, using the “python setup.py bdist_rpm” (based on distutils), but we also wanted to give a try to the "openSUSE:Packaging guidelines” [1].
We mostly use Python and C++ projects, hosted on sourceforge/github or our local repositories. We do want to implement Continuous Delivery, so automatic packaging and deployment to the testing environment is crucial for us.
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. We have not found information on how to build locally packages apart of a link to the Fedora “How to create RPM packages” [3]. There is also a possibility to setup our private OBS system, but maybe it is too complicated solution for what we need right now.
Could you provide us a guide on how to do packaging in the most compatible with the openSUSE standards way.
Thanks a lot for your help! Zibi
[1] https://en.opensuse.org/openSUSE:Packaging_guidelines [2] https://en.opensuse.org/Portal:Build_Service/Documentation [3] http://fedoraproject.org/wiki/How_to_create_an_RPM_package
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
I would say you already have the links you need. My packaging work is based on 3 things: 1- the documentation in the wiki 2- the documentation in the fedora wiki 3- other existing rpms which I use as example openSUSE and Fedora share a lot of things, being RPM one of them. Most documentation on Fedora wiki pages can be used safely on openSUSE package. However, openSUSE adds some things on top, like macros, which you can find in the openSUSE kiwi pages. If you don't want to use the build service, you can try to use rpmbuild command, and then use createrepo command to create your own repo with your packages you will create. On 01/21/2016 04:34 PM, Zbigniew Reszela wrote:
Hello,
In my institute we are selecting the operating system and Leap 42.1 is a strong candidate.
In the selection process we are deeply analyzing the packaging and package management aspects. Currently we use openSUSE 11.1 and some custom GUI packaging and installation tools based on RPM. With the new OS we would like to follow the “packaging good practices” of the distribution. We have already tried building packages for the python projects, using the “python setup.py bdist_rpm” (based on distutils), but we also wanted to give a try to the "openSUSE:Packaging guidelines” [1].
We mostly use Python and C++ projects, hosted on sourceforge/github or our local repositories. We do want to implement Continuous Delivery, so automatic packaging and deployment to the testing environment is crucial for us.
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. We have not found information on how to build locally packages apart of a link to the Fedora “How to create RPM packages” [3]. There is also a possibility to setup our private OBS system, but maybe it is too complicated solution for what we need right now.
Could you provide us a guide on how to do packaging in the most compatible with the openSUSE standards way.
Thanks a lot for your help! Zibi
[1] https://en.opensuse.org/openSUSE:Packaging_guidelines [2] https://en.opensuse.org/Portal:Build_Service/Documentation [3] http://fedoraproject.org/wiki/How_to_create_an_RPM_package
Hi, Am Donnerstag, 21. Januar 2016, 16:34:46 schrieb Zbigniew Reszela:
In my institute we are selecting the operating system and Leap 42.1 is a strong candidate.
Good :-) [...]
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. We have not found information on how to build locally packages apart of a link to the Fedora How to create RPM packages [3]. There is also a possibility to setup our private OBS system, but maybe it is too complicated solution for what we need right now.
next to what already was said - you can use the openSUSE build server and nevertheless build packages locally, without the need to publish them. An own OBS instance would nevertheless be the more safe way Cheers Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public.
I disagree. When you get a OBS login you automatically get a home project (and any sub-projects you create). Within the home project you have to make no guarantees of support etc to anyone else. You establish your own rules for availability, support, etc. If anyone uses your packages, it is a buyer beware situation unless they talk to you and get a support commitment. The only fundamental reason I know of not to use your home project for an internal package management system is if any of these are true: - The packages are not opensource - in general OBS is available to host packaging of opensource packages only - The packages are illegal in Germany (hacking tools mostly) - Despite a package being opensource, it contains code that violates German or US copyright laws If none of those are an issue then, the public OBS server should work for you. If any of those are an issue, you can still consider operating a private instance of OBS at your university. I have no experience with that, but a lot of people have and the full OBS system is available as an appliance for easy installation (as I understand). Hope that helps, Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu 21 Jan 2016 04:13:33 PM CST, Greg Freemyer wrote:
On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public.
I disagree.
When you get a OBS login you automatically get a home project (and any sub-projects you create).
Within the home project you have to make no guarantees of support etc to anyone else. You establish your own rules for availability, support, etc. If anyone uses your packages, it is a buyer beware situation unless they talk to you and get a support commitment.
The only fundamental reason I know of not to use your home project for an internal package management system is if any of these are true:
- The packages are not opensource - in general OBS is available to host packaging of opensource packages only
- The packages are illegal in Germany (hacking tools mostly)
- Despite a package being opensource, it contains code that violates German or US copyright laws
If none of those are an issue then, the public OBS server should work for you.
If any of those are an issue, you can still consider operating a private instance of OBS at your university. I have no experience with that, but a lot of people have and the full OBS system is available as an appliance for easy installation (as I understand).
Hope that helps, Greg -- Greg Freemyer www.IntelligentAvatar.net Hi There are a number of packages that I build locally via osc (as in use OBS package resources) that never appear in my home projects (as in checked in), just reside as a generic package name on OBS and disabled... I use a local repo to provide to my systems.... ;)
-- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 SP1|GNOME 3.10.4|3.12.51-60.25-default up 7:19, 5 users, load average: 0.15, 0.35, 0.38 CPU AMD A4-5150M @ 2.70GHz | GPU Radeon HD 8350G -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello again, First of all many thanks to all of you for your fast replies. And sorry for dropping a message without a subject. I tried to recompile all your hints below, and replied with more questions in between them. I have already some feeling about some of these issues, but I wanted to ensure myself with the opinion of experts. I hope that I'm not abusing your mailing list with this... On 01/21/2016 05:00 PM, Jan Engelhardt wrote:
On Thursday 2016-01-21 16:34, Zbigniew Reszela wrote:
In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public.
It's a misconception, fueled by misnomer. OBS (OpenBuildService) is the software which drives build.opensuse.org, the latter of which people incidentally also call OBS (openSUSE's build service). Not to mention that the guys from OBS (Openbroadcast studio) also regularly lose their way into the OBS IRC channel(s).
So, OBS is also for private use.
Thanks, now I undestand the difference. I will try to not use the accronym from now on in order to avoid confussion. On 01/21/2016 05:03 PM, Darin Perusich wrote:
You can setup a private OBS instance and manage all your "internal" packages and packaging there for any of the supported distro's. In the past I ran a private OBS instance and had packages for a few openSUSE versions, SLES, RHEL/CentOS. You can link the private instance, package and or projects, against the public service for dependency handling, it's super flexible and will simplify packaging immensely.
https://en.opensuse.org/openSUSE:Build_Service_private_instance -- Later, Darin
I would say you already have the links you need. My packaging work is
After reading a little bit about the OpenBuildService it looks that linking and layering features are very powerfull. And the possibility of linking dependencies between the openSUSE's build service and the private OpenBuildService is definitily an advantage. Does the OpenBuildService provide the web interface similar to openSUSE's build service? Or it works only with the osc commands? On 01/21/2016 05:09 PM, Jordi Massaguer Pla wrote: based on 3 things:
1- the documentation in the wiki 2- the documentation in the fedora wiki 3- other existing rpms which I use as example
openSUSE and Fedora share a lot of things, being RPM one of them. Most
documentation on Fedora wiki pages can be used safely on openSUSE package. However, openSUSE adds some things on top, like macros, which you can find in the openSUSE kiwi pages.
If you don't want to use the build service, you can try to use rpmbuild
command, and then use createrepo command to create your own repo with your packages you will create. After making the first tests with the openSUSE's build service it seems to be a great tool! In the evaluation process we will start with openSUSE's build service and threat the rpmbuild, createrepo, etc as plan b. On 01/21/2016 08:49 PM, Axel Braun wrote:
Am Donnerstag, 21. Januar 2016, 16:34:46 schrieb Zbigniew Reszela:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. We have not found information on how to build locally packages apart of a link to the Fedora How to create RPM packages [3]. There is also a possibility to setup our private OBS system, but maybe it is too complicated solution for what we need right now.
next to what already was said - you can use the openSUSE build server and nevertheless build packages locally, without the need to publish them.
An own OBS instance would nevertheless be the more safe way
On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our
Some questions regarding building packages locally: * Having an account in the openSUSE's build service is still a requirement? * Having the source and spec file in the openSUSE's build service is a requirement? * By not publishing them you refer to not publishing the output package to the repository provided by the openSUSE's build service? On 01/21/2016 10:13 PM, Greg Freemyer wrote: projects.
In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. I disagree.
When you get a OBS login you automatically get a home project (and any sub-projects you create).
Within the home project you have to make no guarantees of support etc to anyone else. You establish your own rules for availability, support, etc. If anyone uses your packages, it is a buyer beware situation unless they talk to you and get a support commitment.
The only fundamental reason I know of not to use your home project for an internal package management system is if any of these are true:
- The packages are not opensource - in general OBS is available to host packaging of opensource packages only
- The packages are illegal in Germany (hacking tools mostly)
- Despite a package being opensource, it contains code that violates German or US copyright laws
If none of those are an issue then, the public OBS server should work for you.
If any of those are an issue, you can still consider operating a private instance of OBS at your university. I have no experience with that, but a lot of people have and the full OBS system is available as an appliance for easy installation (as I understand).
Hope that helps, Greg
Some questions about the use of home project: * Is the home project and its packages (source and spec file) visible to the rest of the openSUSE's build service users? or maybe even public in the Internet? On 01/21/2016 10:53 PM, Malcolm wrote:
On Thu 21 Jan 2016 04:13:33 PM CST, Greg Freemyer wrote:
On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public.
I disagree.
When you get a OBS login you automatically get a home project (and any sub-projects you create).
Within the home project you have to make no guarantees of support etc to anyone else. You establish your own rules for availability, support, etc. If anyone uses your packages, it is a buyer beware situation unless they talk to you and get a support commitment.
The only fundamental reason I know of not to use your home project for an internal package management system is if any of these are true:
- The packages are not opensource - in general OBS is available to host packaging of opensource packages only
- The packages are illegal in Germany (hacking tools mostly)
- Despite a package being opensource, it contains code that violates German or US copyright laws
If none of those are an issue then, the public OBS server should work for you.
If any of those are an issue, you can still consider operating a private instance of OBS at your university. I have no experience with that, but a lot of people have and the full OBS system is available as an appliance for easy installation (as I understand).
Hope that helps, Greg -- Greg Freemyer www.IntelligentAvatar.net Hi There are a number of packages that I build locally via osc (as in use OBS package resources) that never appear in my home projects (as in checked in), just reside as a generic package name on OBS and disabled... I use a local repo to provide to my systems.... ;)
If I understand well, you have your openSUSE's build service account hence you have the home project. You have also defined the packages there. But you use the "osc build" command to build the packages locally and upload the output packages to your local repo. Do you still need to go through the openSUSE's build service to update the source? Cheers, Zibi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri 22 Jan 2016 04:57:35 PM CST, Zbigniew Reszela wrote: <snip>
Hi There are a number of packages that I build locally via osc (as in use OBS package resources) that never appear in my home projects (as in checked in), just reside as a generic package name on OBS and disabled... I use a local repo to provide to my systems.... ;)
If I understand well, you have your openSUSE's build service account hence you have the home project. You have also defined the packages there. But you use the "osc build" command to build the packages locally and upload the output packages to your local repo. Do you still need to go through the openSUSE's build service to update the source?
Hi No, it's all done locally, all that exists on OBS for example; https://build.opensuse.org/package/show/home:malcolmlewis/dummy_pkg I actually use the one in my TESTING repo, which has repositories added, but you can build against other projects via osc without them being added. I then move the built rpms to a local http server and use createrepo command to update/add. -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 SP1|GNOME 3.10.4|3.12.51-60.25-default up 1 day 1:42, 4 users, load average: 0.10, 0.22, 0.30 CPU AMD A4-5150M @ 2.70GHz | GPU Radeon HD 8350G -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, 22 Jan 2016 16:57:35 +0100 "Zbigniew Reszela" <zreszela@cells.es> wrote:
Hello again,
First of all many thanks to all of you for your fast replies. And sorry for dropping a message without a subject. I tried to recompile all your hints below, and replied with more questions in between them. I have already some feeling about some of these issues, but I wanted to ensure myself with the opinion of experts. I hope that I'm not abusing your mailing list with this...
On 01/21/2016 05:03 PM, Darin Perusich wrote:
You can setup a private OBS instance and manage all your "internal" packages and packaging there for any of the supported distro's. In the past I ran a private OBS instance and had packages for a few openSUSE versions, SLES, RHEL/CentOS. You can link the private instance, package and or projects, against the public service for dependency handling, it's super flexible and will simplify packaging immensely.
https://en.opensuse.org/openSUSE:Build_Service_private_instance -- Later, Darin
After reading a little bit about the OpenBuildService it looks that linking and layering features are very powerfull. And the possibility of linking dependencies between the openSUSE's build service and the private OpenBuildService is definitily an advantage. Does the OpenBuildService provide the web interface similar to openSUSE's build service? Or it works only with the osc commands?
It works with both. In SUSE we use it also for building our enterprise product that have to be signed by our key. If you deploy your own OpenBuildService it looks very similar to one in build.opensuse.org just without opensuse branding.
On 01/21/2016 08:49 PM, Axel Braun wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. We have not found information on how to build locally packages apart of a link to the Fedora “How to create RPM packages” [3]. There is also a possibility to setup our private OBS system, but maybe it is too complicated solution for what we need right now. next to what already was said - you can use the openSUSE build server and nevertheless build packages locally, without the need to
Am Donnerstag, 21. Januar 2016, 16:34:46 schrieb Zbigniew Reszela: publish them.
An own OBS instance would nevertheless be the more safe way
Some questions regarding building packages locally: * Having an account in the openSUSE's build service is still a requirement?
yes, as you need to do dependency resolution and possible download on server ( like you have your secret project S and it depends on boost, so it read from spec what is required and install it to your local chroot.
* Having the source and spec file in the openSUSE's build service is a requirement?
no, as you can see below you can have empty dummy_package and you can do osc build after copying your files. Unless you call osc commit, it won't be send to server. ( it is same like svn for example )
* By not publishing them you refer to not publishing the output package to the repository provided by the openSUSE's build service?
you can prevent publishing in repository, so it means, if you send sources to server, server can build it, but result of build is not available in public repository ( but can be downloaded via API ).
On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our
On 01/21/2016 10:13 PM, Greg Freemyer wrote: projects.
In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. I disagree.
When you get a OBS login you automatically get a home project (and any sub-projects you create).
Within the home project you have to make no guarantees of support etc to anyone else. You establish your own rules for availability, support, etc. If anyone uses your packages, it is a buyer beware situation unless they talk to you and get a support commitment.
The only fundamental reason I know of not to use your home project for an internal package management system is if any of these are true:
- The packages are not opensource - in general OBS is available to host packaging of opensource packages only
- The packages are illegal in Germany (hacking tools mostly)
- Despite a package being opensource, it contains code that violates German or US copyright laws
If none of those are an issue then, the public OBS server should work for you.
If any of those are an issue, you can still consider operating a private instance of OBS at your university. I have no experience with that, but a lot of people have and the full OBS system is available as an appliance for easy installation (as I understand).
Hope that helps, Greg
Some questions about the use of home project: * Is the home project and its packages (source and spec file) visible to the rest of the openSUSE's build service users? or maybe even public in the Internet?
yes, it is visible. That is reason why you cannot use it for copyrighted or law breaking projects.
On 01/21/2016 10:53 PM, Malcolm wrote:
On Thu 21 Jan 2016 04:13:33 PM CST, Greg Freemyer wrote:
On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public.
I disagree.
When you get a OBS login you automatically get a home project (and any sub-projects you create).
Within the home project you have to make no guarantees of support etc to anyone else. You establish your own rules for availability, support, etc. If anyone uses your packages, it is a buyer beware situation unless they talk to you and get a support commitment.
The only fundamental reason I know of not to use your home project for an internal package management system is if any of these are true:
- The packages are not opensource - in general OBS is available to host packaging of opensource packages only
- The packages are illegal in Germany (hacking tools mostly)
- Despite a package being opensource, it contains code that violates German or US copyright laws
If none of those are an issue then, the public OBS server should work for you.
If any of those are an issue, you can still consider operating a private instance of OBS at your university. I have no experience with that, but a lot of people have and the full OBS system is available as an appliance for easy installation (as I understand).
Hope that helps, Greg -- Greg Freemyer www.IntelligentAvatar.net Hi There are a number of packages that I build locally via osc (as in use OBS package resources) that never appear in my home projects (as in checked in), just reside as a generic package name on OBS and disabled... I use a local repo to provide to my systems.... ;)
If I understand well, you have your openSUSE's build service account hence you have the home project. You have also defined the packages there. But you use the "osc build" command to build the packages locally and upload the output packages to your local repo. Do you still need to go through the openSUSE's build service to update the source?
it basically works in a way, that you copy files to your dummy checkout, call `osc build` and copy resulted rpms to your target location.
Cheers, Zibi
In general my recommendation is if you have more then more project and if it have dependencies between it is easier to use OpenBuildService. Public one on openSUSE or private one, what fits your needs. Josef -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
From what we see, there is no "union" repository of the home project that would include all the binaries of the sub-projects? Do you know how to achieve that? It is also possible that we would need to introduce categories for our
Hello, Many thanks to Malcolm and Josef for your replies. All the issues are clear now. Our evaluation process is advancing, and the openSUSE's build service is gaining a lot of points! However we have some more questions about it. First of all, is this the correct mailing list to ask? or we should move to: opensuse-buildservice mailing list? In any case, I write here the questions, and please let me know if I should change the mailing list. Question 1: How to maintain multiple versions of the package in the openSUSE's build service repository? We have observed that submitting new sources with bumped version number is rebuilding the project and the new binary (rpm) is substituting the previously existing one. We would like to maintain multiple versions of the binaries in the repository. In our site we are upgrading software gradually, and multiple stable versions coexist in production. We have found this best practice [1] explaining that the sub-projects are the way to implement it. Could your confirm that? I imagine that we need to create a hierarchy of sub-projects dangling from our home e.g. * HOME ** Project1 *** Unstable *** 1.0.0 *** 1.1.1 *** 1.2.0 *** etc. ** Project2 *** Unstable *** 1.0.0 *** 2.0.0 *** etc. ** etc. Question 2: How to obtain one common repository with all the binaries coming from many sub-projects that have multiple versions? projects: e.g. Libraries, Applications, Drivers, etc.. but I imagine that it could be solved by adding one more level in the sub-projects hierarchy. Question 3: How to trigger dowstream tasks once the package is build? Our final goal is to implement Continuous Delivery (CD) pipelines for our projects. We see that the openSUSE's build service can upload sources from the GIT repositories directly. Could you confirm that this is the proper way to implement upstream repository triggering the openSUSE's build service? But how to connect dowstream tasks? Is it possible to define webhooks in the openSUSE's build service, or some other mechanism that would facilitate implementation of CD pipelines? Cheers, Zibi [1] http://openbuildservice.org/help/manuals/obs-best-practices/cha.obs.best-pra...
On Fri, 22 Jan 2016 16:57:35 +0100 "Zbigniew Reszela" <zreszela@cells.es> wrote:
Hello again,
First of all many thanks to all of you for your fast replies. And sorry for dropping a message without a subject. I tried to recompile all your hints below, and replied with more questions in between them. I have already some feeling about some of these issues, but I wanted to ensure myself with the opinion of experts. I hope that I'm not abusing your mailing list with this...
On 01/21/2016 05:03 PM, Darin Perusich wrote:
You can setup a private OBS instance and manage all your "internal" packages and packaging there for any of the supported distro's. In the past I ran a private OBS instance and had packages for a few openSUSE versions, SLES, RHEL/CentOS. You can link the private instance, package and or projects, against the public service for dependency handling, it's super flexible and will simplify packaging immensely.
https://en.opensuse.org/openSUSE:Build_Service_private_instance -- Later, Darin
After reading a little bit about the OpenBuildService it looks that linking and layering features are very powerfull. And the possibility of linking dependencies between the openSUSE's build service and the private OpenBuildService is definitily an advantage. Does the OpenBuildService provide the web interface similar to openSUSE's build service? Or it works only with the osc commands?
It works with both. In SUSE we use it also for building our enterprise product that have to be signed by our key. If you deploy your own OpenBuildService it looks very similar to one in build.opensuse.org just without opensuse branding.
On 01/21/2016 08:49 PM, Axel Braun wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. We have not found information on how to build locally packages apart of a link to the Fedora âHow to create RPM packagesâ [3]. There is also a possibility to setup our private OBS system, but maybe it is too complicated solution for what we need right now. next to what already was said - you can use the openSUSE build server and nevertheless build packages locally, without the need to
Am Donnerstag, 21. Januar 2016, 16:34:46 schrieb Zbigniew Reszela: publish them.
An own OBS instance would nevertheless be the more safe way
Some questions regarding building packages locally: * Having an account in the openSUSE's build service is still a requirement?
yes, as you need to do dependency resolution and possible download on server ( like you have your secret project S and it depends on boost, so it read from spec what is required and install it to your local chroot.
* Having the source and spec file in the openSUSE's build service is a requirement?
no, as you can see below you can have empty dummy_package and you can do osc build after copying your files. Unless you call osc commit, it won't be send to server. ( it is same like svn for example )
* By not publishing them you refer to not publishing the output package to the repository provided by the openSUSE's build service?
you can prevent publishing in repository, so it means, if you send sources to server, server can build it, but result of build is not available in public repository ( but can be downloaded via API ).
On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our
On 01/21/2016 10:13 PM, Greg Freemyer wrote: projects.
In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. I disagree.
When you get a OBS login you automatically get a home project (and any sub-projects you create).
Within the home project you have to make no guarantees of support etc to anyone else. You establish your own rules for availability, support, etc. If anyone uses your packages, it is a buyer beware situation unless they talk to you and get a support commitment.
The only fundamental reason I know of not to use your home project for an internal package management system is if any of these are true:
- The packages are not opensource - in general OBS is available to host packaging of opensource packages only
- The packages are illegal in Germany (hacking tools mostly)
- Despite a package being opensource, it contains code that violates German or US copyright laws
If none of those are an issue then, the public OBS server should work for you.
If any of those are an issue, you can still consider operating a private instance of OBS at your university. I have no experience with that, but a lot of people have and the full OBS system is available as an appliance for easy installation (as I understand).
Hope that helps, Greg
Some questions about the use of home project: * Is the home project and its packages (source and spec file) visible to the rest of the openSUSE's build service users? or maybe even public in the Internet?
yes, it is visible. That is reason why you cannot use it for copyrighted or law breaking projects.
On 01/21/2016 10:53 PM, Malcolm wrote:
On Thu 21 Jan 2016 04:13:33 PM CST, Greg Freemyer wrote:
On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public.
I disagree.
When you get a OBS login you automatically get a home project (and any sub-projects you create).
Within the home project you have to make no guarantees of support etc to anyone else. You establish your own rules for availability, support, etc. If anyone uses your packages, it is a buyer beware situation unless they talk to you and get a support commitment.
The only fundamental reason I know of not to use your home project for an internal package management system is if any of these are true:
- The packages are not opensource - in general OBS is available to host packaging of opensource packages only
- The packages are illegal in Germany (hacking tools mostly)
- Despite a package being opensource, it contains code that violates German or US copyright laws
If none of those are an issue then, the public OBS server should work for you.
If any of those are an issue, you can still consider operating a private instance of OBS at your university. I have no experience with that, but a lot of people have and the full OBS system is available as an appliance for easy installation (as I understand).
Hope that helps, Greg -- Greg Freemyer www.IntelligentAvatar.net Hi There are a number of packages that I build locally via osc (as in use OBS package resources) that never appear in my home projects (as in checked in), just reside as a generic package name on OBS and disabled... I use a local repo to provide to my systems.... ;)
If I understand well, you have your openSUSE's build service account hence you have the home project. You have also defined the packages there. But you use the "osc build" command to build the packages locally and upload the output packages to your local repo. Do you still need to go through the openSUSE's build service to update the source?
it basically works in a way, that you copy files to your dummy checkout, call `osc build` and copy resulted rpms to your target location.
Cheers, Zibi
In general my recommendation is if you have more then more project and if it have dependencies between it is easier to use OpenBuildService. Public one on openSUSE or private one, what fits your needs.
Josef -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, 2 Feb 2016 16:18:45 +0100 "Zbigniew Reszela" <zreszela@cells.es> wrote:
Hello,
Many thanks to Malcolm and Josef for your replies. All the issues are clear now. Our evaluation process is advancing, and the openSUSE's build service is gaining a lot of points! However we have some more questions about it. First of all, is this the correct mailing list to ask? or we should move to: opensuse-buildservice mailing list? In any case, I write here the questions, and please let me know if I should change the mailing list.
I think packaging list is fine for this kind of questions. Of course if it is some build service specific one, then maybe above mentioned one is better.
Question 1: How to maintain multiple versions of the package in the openSUSE's build service repository?
We have observed that submitting new sources with bumped version number is rebuilding the project and the new binary (rpm) is substituting the previously existing one. We would like to maintain multiple versions of the binaries in the repository. In our site we are upgrading software gradually, and multiple stable versions coexist in production.
We have found this best practice [1] explaining that the sub-projects are the way to implement it. Could your confirm that?
I imagine that we need to create a hierarchy of sub-projects dangling from our home e.g. * HOME ** Project1 *** Unstable *** 1.0.0 *** 1.1.1 *** 1.2.0 *** etc. ** Project2 *** Unstable *** 1.0.0 *** 2.0.0 *** etc. ** etc.
you basically have three options (I know, maybe there is some switch in build service): 1) freezing as you write above, which is same opensuse did e.g. with releases, that after release it is moved to own repository 2) using suffixes similar to libraries like libgtk, libgtk2 etc. but it is not much usable if you want to have many versions. 3) creating repo outside of build service. Just grab rpm from buildservice and then with `createrepo` script create own repository with whatever rpm you want.
Question 2: How to obtain one common repository with all the binaries coming from many sub-projects that have multiple versions?
From what we see, there is no "union" repository of the home project that would include all the binaries of the sub-projects? Do you know how to achieve that? It is also possible that we would need to introduce categories for our projects: e.g. Libraries, Applications, Drivers, etc.. but I imagine that it could be solved by adding one more level in the sub-projects hierarchy.
I do not know how such union can be created expect creating own repository, but maybe others know.
Question 3: How to trigger dowstream tasks once the package is build?
Our final goal is to implement Continuous Delivery (CD) pipelines for our projects. We see that the openSUSE's build service can upload sources from the GIT repositories directly. Could you confirm that this is the proper way to implement upstream repository triggering the openSUSE's build service? But how to connect dowstream tasks? Is it possible to define webhooks in the openSUSE's build service, or some other mechanism that would facilitate implementation of CD pipelines?
I am not sure, but few years ago such mechanism missing, but maybe it is already implemented?
Cheers, Zibi
[1] http://openbuildservice.org/help/manuals/obs-best-practices/cha.obs.best-pra...
On Fri, 22 Jan 2016 16:57:35 +0100 "Zbigniew Reszela" <zreszela@cells.es> wrote:
Hello again,
First of all many thanks to all of you for your fast replies. And sorry for dropping a message without a subject. I tried to recompile all your hints below, and replied with more questions in between them. I have already some feeling about some of these issues, but I wanted to ensure myself with the opinion of experts. I hope that I'm not abusing your mailing list with this...
On 01/21/2016 05:03 PM, Darin Perusich wrote:
You can setup a private OBS instance and manage all your "internal" packages and packaging there for any of the supported distro's. In the past I ran a private OBS instance and had packages for a few openSUSE versions, SLES, RHEL/CentOS. You can link the private instance, package and or projects, against the public service for dependency handling, it's super flexible and will simplify packaging immensely.
https://en.opensuse.org/openSUSE:Build_Service_private_instance -- Later, Darin
After reading a little bit about the OpenBuildService it looks that linking and layering features are very powerfull. And the possibility of linking dependencies between the openSUSE's build service and the private OpenBuildService is definitily an advantage. Does the OpenBuildService provide the web interface similar to openSUSE's build service? Or it works only with the osc commands?
It works with both. In SUSE we use it also for building our enterprise product that have to be signed by our key. If you deploy your own OpenBuildService it looks very similar to one in build.opensuse.org just without opensuse branding.
On 01/21/2016 08:49 PM, Axel Braun wrote:
Am Donnerstag, 21. Januar 2016, 16:34:46 schrieb Zbigniew Reszela:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. We have not found information on how to build locally packages apart of a link to the Fedora “How to create RPM packagesâ€_ [3]. There is also a possibility to setup our private OBS system, but maybe it is too complicated solution for what we need right now. next to what already was said - you can use the openSUSE build server and nevertheless build packages locally, without the need to publish them.
An own OBS instance would nevertheless be the more safe way
Some questions regarding building packages locally: * Having an account in the openSUSE's build service is still a requirement?
yes, as you need to do dependency resolution and possible download on server ( like you have your secret project S and it depends on boost, so it read from spec what is required and install it to your local chroot.
* Having the source and spec file in the openSUSE's build service is a requirement?
no, as you can see below you can have empty dummy_package and you can do osc build after copying your files. Unless you call osc commit, it won't be send to server. ( it is same like svn for example )
* By not publishing them you refer to not publishing the output package to the repository provided by the openSUSE's build service?
you can prevent publishing in repository, so it means, if you send sources to server, server can build it, but result of build is not available in public repository ( but can be downloaded via API ).
On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our
On 01/21/2016 10:13 PM, Greg Freemyer wrote: projects.
In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. I disagree.
When you get a OBS login you automatically get a home project (and any sub-projects you create).
Within the home project you have to make no guarantees of support etc to anyone else. You establish your own rules for availability, support, etc. If anyone uses your packages, it is a buyer beware situation unless they talk to you and get a support commitment.
The only fundamental reason I know of not to use your home project for an internal package management system is if any of these are true:
- The packages are not opensource - in general OBS is available to host packaging of opensource packages only
- The packages are illegal in Germany (hacking tools mostly)
- Despite a package being opensource, it contains code that violates German or US copyright laws
If none of those are an issue then, the public OBS server should work for you.
If any of those are an issue, you can still consider operating a private instance of OBS at your university. I have no experience with that, but a lot of people have and the full OBS system is available as an appliance for easy installation (as I understand).
Hope that helps, Greg
Some questions about the use of home project: * Is the home project and its packages (source and spec file) visible to the rest of the openSUSE's build service users? or maybe even public in the Internet?
yes, it is visible. That is reason why you cannot use it for copyrighted or law breaking projects.
On 01/21/2016 10:53 PM, Malcolm wrote:
On Thu 21 Jan 2016 04:13:33 PM CST, Greg Freemyer wrote:
On Thu, Jan 21, 2016 at 10:34 AM, Zbigniew Reszela <zreszela@cells.es> wrote:
Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public.
I disagree.
When you get a OBS login you automatically get a home project (and any sub-projects you create).
Within the home project you have to make no guarantees of support etc to anyone else. You establish your own rules for availability, support, etc. If anyone uses your packages, it is a buyer beware situation unless they talk to you and get a support commitment.
The only fundamental reason I know of not to use your home project for an internal package management system is if any of these are true:
- The packages are not opensource - in general OBS is available to host packaging of opensource packages only
- The packages are illegal in Germany (hacking tools mostly)
- Despite a package being opensource, it contains code that violates German or US copyright laws
If none of those are an issue then, the public OBS server should work for you.
If any of those are an issue, you can still consider operating a private instance of OBS at your university. I have no experience with that, but a lot of people have and the full OBS system is available as an appliance for easy installation (as I understand).
Hope that helps, Greg -- Greg Freemyer www.IntelligentAvatar.net Hi There are a number of packages that I build locally via osc (as in use OBS package resources) that never appear in my home projects (as in checked in), just reside as a generic package name on OBS and disabled... I use a local repo to provide to my systems.... ;)
If I understand well, you have your openSUSE's build service account hence you have the home project. You have also defined the packages there. But you use the "osc build" command to build the packages locally and upload the output packages to your local repo. Do you still need to go through the openSUSE's build service to update the source?
it basically works in a way, that you copy files to your dummy checkout, call `osc build` and copy resulted rpms to your target location.
Cheers, Zibi
In general my recommendation is if you have more then more project and if it have dependencies between it is easier to use OpenBuildService. Public one on openSUSE or private one, what fits your needs.
Josef -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Feb 2, 2016 at 11:07 AM, Josef Reidinger <jreidinger@suse.cz> wrote:
Question 2: How to obtain one common repository with all the binaries coming from many sub-projects that have multiple versions?
From what we see, there is no "union" repository of the home project that would include all the binaries of the sub-projects? Do you know how to achieve that? It is also possible that we would need to introduce categories for our projects: e.g. Libraries, Applications, Drivers, etc.. but I imagine that it could be solved by adding one more level in the sub-projects hierarchy.
I do not know how such union can be created expect creating own repository, but maybe others know.
OBS heavily uses branched and linked projects. It is specifically designed to manage a full distro develoment and release process. You can re-create the majority of the process in you home project if that is what you need to do. factory is a union of all "released" packages on OBS. It has thousands of packages in it. Every package in factory is linked to a devel project. the devel projects are grouped by working groups. Most people try to keep the devel projects fairly stable, so they are only out of sync from factory for a few days at a time. Then they have the devel projects linked to an unstable (or home:) project where they work out there packaging / upgrade issues. I'm sure some of the more complex projects have 4 or more tiers or projects permanently setup. Thus if you want the main home project to be a union just like factory is, then create all the packages there. Then branch/link them to the sub-projects as you want to organize them. Once you have a 3-tier set of projects / packages setup with the links/branches your workflow becomes: - Modify package in an unstable project. Test it until satisfied with packaging/upgrade functionality - Use a SR (submit request) to submit the changes from unstable to devel. Continue testing with a more complete set of packages. Since this is a stable sub-project, testing should be done quickly. If it fails, revert the submit. - Once you've tested the package in the stable sub-project submit it to your union project. Again test immediately and revert the change if testing fails. == if you want to implement "releases" of the union project, then on occasion create a parallel project and copy everything from the union project to that static "release" project. That is how openSUSE did its releases prior to Leap. (ie. a new release project was created and then all the packages in factory were copied from factory to the new release project). === osc is a very powerful command line tool. It can help you make the above process very straight forward to implement. It has capabilities like: - List all packages in a project, - Link/branch a package from project to another, - output the differences between 2 linked packages - Copy a package from one project to another (without creating a link) - Submit a project from the current package to the one it is linked to. Good Luck, Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (9)
-
Axel Braun -
Darin Perusich -
Greg Freemyer -
Jan Engelhardt -
Jordi Massaguer Pla -
Josef Reidinger -
Kyrill Detinov -
Malcolm -
Zbigniew Reszela