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 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 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 16:57:35 +0100 "Zbigniew Reszela" 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 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 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

On Tue, 2 Feb 2016 16:18:45 +0100 "Zbigniew Reszela" 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" 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 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 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