Announce: Conditional Build Dependencies per Project
Hi, Our base packages include support for all sorts of features, making our base OS very large due to dependencies. While this is not a problem for e.g. openSUSE Tumbleweed, where the extra packages do not really matter in the overall size, it is a big problem when building a small single-purpose OS where you want something really small without any unnecessary packages. Like ALP. The "useless" packages create yet another problem: Libraries are installed for features that are not supported or do not work. E.g. AppArmor and SELinux are exclusive, so why should e.g. ALP ship AppArmor that can't work and isn't supported, but creates a high maintenance overhead on all sides without any benefit? We use already %bcond in our spec files set in the project config for various reasons, one is to bootstrap the distro. Another reason is, that it looks like as some maintainers build already smaller versions of some packages for their need in their projects. To avoid that e.g. ALP is shipped with AppArmor and SELinux, while only SELinux will be used, we decided to "formalize" and document this: https://en.opensuse.org/openSUSE:Package_Conditional_Build_Dependencies 85% of the keywords are already used today in projects. What does this mean for you? 1. if somebody added this %bcond to your packages, please accept them and forward them to Factory. 2. if you are working on a package and have dependencies mentioned in the list, please consider to make your package configurable in this regard. 3. If we create bug reports for ALP since you are a maintainer of a core package which has dependencies we don't want to see, please work on them with a higher priority. 4. Yes, it is known that you cannot build every package without this dependencies. Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Fri, 24 Feb 2023, Thorsten Kukuk wrote:
Hi,
Our base packages include support for all sorts of features, making our base OS very large due to dependencies. While this is not a problem for e.g. openSUSE Tumbleweed, where the extra packages do not really matter in the overall size, it is a big problem when building a small single-purpose OS where you want something really small without any unnecessary packages. Like ALP.
The "useless" packages create yet another problem: Libraries are installed for features that are not supported or do not work. E.g. AppArmor and SELinux are exclusive, so why should e.g. ALP ship AppArmor that can't work and isn't supported, but creates a high maintenance overhead on all sides without any benefit?
We use already %bcond in our spec files set in the project config for various reasons, one is to bootstrap the distro. Another reason is, that it looks like as some maintainers build already smaller versions of some packages for their need in their projects. To avoid that e.g. ALP is shipped with AppArmor and SELinux, while only SELinux will be used, we decided to "formalize" and document this:
https://en.opensuse.org/openSUSE:Package_Conditional_Build_Dependencies
85% of the keywords are already used today in projects.
What does this mean for you? 1. if somebody added this %bcond to your packages, please accept them and forward them to Factory. 2. if you are working on a package and have dependencies mentioned in the list, please consider to make your package configurable in this regard. 3. If we create bug reports for ALP since you are a maintainer of a core package which has dependencies we don't want to see, please work on them with a higher priority. 4. Yes, it is known that you cannot build every package without this dependencies.
Thorsten - please document what functionality is controlled by the respective keywords. For some it's reasonably obvious but TLC (three letter acronyms) have too many overloaded meanings. What's faac and faad? I suppose ada is the programming language with this name - I wonder why you didn't add d (yes, 'd') as well? What's sbl? I guess who's supposed to know will know, but then documentation helps. Richard.
On Fri, Feb 24, Richard Biener wrote:
Thorsten - please document what functionality is controlled by the respective keywords. For some it's reasonably obvious but TLC (three letter acronyms) have too many overloaded meanings. What's faac and faad? I suppose ada is the programming language with this name - I wonder why you didn't add d (yes, 'd') as well?
What's sbl?
I guess who's supposed to know will know, but then documentation helps.
I think this is a task for this developers and release managers, who introduced them and are using them. I don't know, too. As written, the majority is already in use since a long time. And why should I add 'd'? It's not on the problematic list for ALP and it looks like not used by other people. We also didn't add "C", "C++" or golang ;) Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Fri, 24 Feb 2023, Thorsten Kukuk wrote:
On Fri, Feb 24, Richard Biener wrote:
Thorsten - please document what functionality is controlled by the respective keywords. For some it's reasonably obvious but TLC (three letter acronyms) have too many overloaded meanings. What's faac and faad? I suppose ada is the programming language with this name - I wonder why you didn't add d (yes, 'd') as well?
What's sbl?
I guess who's supposed to know will know, but then documentation helps.
I think this is a task for this developers and release managers, who introduced them and are using them. I don't know, too. As written, the majority is already in use since a long time.
And why should I add 'd'? It's not on the problematic list for ALP and it looks like not used by other people. We also didn't add "C", "C++" or golang ;)
I guess then I don't understand why you added (OK, I'm now second guessing you didn't _add_) 'ada'. I suppose it doesn't actually refer to the programming language Ada. GCC needs a D compiler to build the D language frontend, just like with the Ada compiler dependence for building the Ada language frontend. Richard.
On Fri, Feb 24, Richard Biener wrote:
I guess then I don't understand why you added (OK, I'm now second guessing you didn't _add_) 'ada'.
As written: this list is taken out of OBS what is already used today. The only new entry is "kerberos". Everything else is there and in use since a longer time. If somebody knows why he added something or what it really means (especially for the not unique three letter acronyms), please add it. It's a wiki, and a wiki lives from the fact, that everybody added the missing pieces he knows. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Fri, 24 Feb 2023 15:43:37 +0100 Thorsten Kukuk <kukuk@suse.de>:
The only new entry is "kerberos". Everything else is there and in use since a longer time.
I doubt that 'ffmpeg' for example is still in active use. This specific conditional can be safely removed everywhere because what it used to hide is always present for the consumers since a few years. As Richard said, someone needs to walk through this list and document what each individual conditionally really is supposed to mean by now. Olaf
On Fri, 2023-02-24 at 14:19 +0000, Richard Biener wrote:
Thorsten - please document what functionality is controlled by the respective keywords. For some it's reasonably obvious but TLC (three letter acronyms) have too many overloaded meanings. What's faac and faad? I suppose ada is the programming language with this name - I wonder why you didn't add d (yes, 'd') as well?
Most of those feature are likely understood by people using them: faac / faad are codecs which are disabled in the packages inside OBS - but enabled on 3rd-party OBS instances when rebuilding the same sources
What's sbl?
sbl is a package name, refering to Screen reader for the Linux console This bcond was introduced in 2013 to allow stagings to have slightly less noise (by now we can probably give that up - as speechd and orca are in the rings anyway - otoh, who even knows if that works in the installer?) I'll try to add some comments on the wiki to the 'less obvious ones' Cheers, Dominique
On Friday 2023-02-24 16:37, Dominique Leuenberger wrote:
On Fri, 2023-02-24 at 14:19 +0000, Richard Biener wrote:
Thorsten - please document what functionality is controlled by the respective keywords. For some it's reasonably obvious but TLC (three letter acronyms) have too many overloaded meanings. What's faac and faad? I suppose ada is the programming language with this name - I wonder why you didn't add d (yes, 'd') as well?
Most of those feature are likely understood by people using them:
faac / faad are codecs which are disabled in the packages inside OBS - but enabled on 3rd-party OBS instances when rebuilding the same sources
But for that, we normally have %BUILD_ORIG.
On Fri, 2023-02-24 at 17:41 +0100, Jan Engelhardt wrote:
On Friday 2023-02-24 16:37, Dominique Leuenberger wrote:
On Fri, 2023-02-24 at 14:19 +0000, Richard Biener wrote:
Thorsten - please document what functionality is controlled by the respective keywords. For some it's reasonably obvious but TLC (three letter acronyms) have too many overloaded meanings. What's faac and faad? I suppose ada is the programming language with this name - I wonder why you didn't add d (yes, 'd') as well?
Most of those feature are likely understood by people using them:
faac / faad are codecs which are disabled in the packages inside OBS - but enabled on 3rd-party OBS instances when rebuilding the same sources
But for that, we normally have %BUILD_ORIG.
Not exclusively - as different 3rd-parties have different rules
On Fri, 2023-02-24 at 16:37 +0100, Dominique Leuenberger wrote:
On Fri, 2023-02-24 at 14:19 +0000, Richard Biener wrote:
Thorsten - please document what functionality is controlled by the respective keywords. For some it's reasonably obvious but TLC (three letter acronyms) have too many overloaded meanings. What's faac and faad? I suppose ada is the programming language with this name - I wonder why you didn't add d (yes, 'd') as well?
Most of those feature are likely understood by people using them:
faac / faad are codecs which are disabled in the packages inside OBS - but enabled on 3rd-party OBS instances when rebuilding the same sources
What's sbl?
sbl is a package name, refering to Screen reader for the Linux console
While we are at it: These bconds should be reworked to user proper namespaces. bconds that are specific a group of packages (like the faac/faad above) should use a prefix that clarifies their meaning, like codec_faac. package- specific bconds should probably use the package name as namespace prefix. Only general options that affect the distribution as a whole should be allowed to use 3-letter or 4-letter (actually: non-namespaced) acronyms. Regards, Martin
On Fri, Feb 24, 2023 at 9:08 AM Thorsten Kukuk <kukuk@suse.de> wrote:
Hi,
Our base packages include support for all sorts of features, making our base OS very large due to dependencies. While this is not a problem for e.g. openSUSE Tumbleweed, where the extra packages do not really matter in the overall size, it is a big problem when building a small single-purpose OS where you want something really small without any unnecessary packages. Like ALP.
The "useless" packages create yet another problem: Libraries are installed for features that are not supported or do not work. E.g. AppArmor and SELinux are exclusive, so why should e.g. ALP ship AppArmor that can't work and isn't supported, but creates a high maintenance overhead on all sides without any benefit?
We use already %bcond in our spec files set in the project config for various reasons, one is to bootstrap the distro. Another reason is, that it looks like as some maintainers build already smaller versions of some packages for their need in their projects. To avoid that e.g. ALP is shipped with AppArmor and SELinux, while only SELinux will be used, we decided to "formalize" and document this:
https://en.opensuse.org/openSUSE:Package_Conditional_Build_Dependencies
85% of the keywords are already used today in projects.
What does this mean for you? 1. if somebody added this %bcond to your packages, please accept them and forward them to Factory. 2. if you are working on a package and have dependencies mentioned in the list, please consider to make your package configurable in this regard. 3. If we create bug reports for ALP since you are a maintainer of a core package which has dependencies we don't want to see, please work on them with a higher priority. 4. Yes, it is known that you cannot build every package without this dependencies.
Uhh, no? If someone sends me an SR to add %bconds, expecting automatic acceptance is not acceptable. It's always a maintenance judgement call. And if you're going to have predefined %bconds you expect everyone to use, please include descriptions for them. Assuming people know what they mean and what they're for is not a good idea. I don't even know what some of those are. -- 真実はいつも一つ！/ Always, there's only one truth!
https://en.opensuse.org/openSUSE:Package_Conditional_Build_Dependencies
Its a wiki, so we can expand the list, right? Petr -- Have a lot of fun..
On Fri, Feb 24, pgajdos wrote:
https://en.opensuse.org/openSUSE:Package_Conditional_Build_Dependencies
Its a wiki, so we can expand the list, right?
Of course, if you miss something or need something just add it. This list is by no means complete nor final. But please add a short description, so that we know in the future what it means. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Citeren Thorsten Kukuk <kukuk@suse.de>:
What does this mean for you? 1. if somebody added this %bcond to your packages, please accept them and forward them to Factory. 2. if you are working on a package and have dependencies mentioned in the list, please consider to make your package configurable in this regard. 3. If we create bug reports for ALP since you are a maintainer of a core package which has dependencies we don't want to see, please work on them with a higher priority. 4. Yes, it is known that you cannot build every package without this dependencies.
Would it be possible to have rpmlint check for these dependencies and emit a warning if the corresponding %bcond is not found in the specfile?
On Saturday 2023-02-25 11:22, Arjen de Korte wrote:
Would it be possible to have rpmlint check for these dependencies and emit a warning if the corresponding %bcond is not found in the specfile?
rpmlint cannot distinguish between (a) xx is optional and the absence of %bcond_xx is unfortunate (b) the absence of %bcond_xx is legit due to package hard-requires xx and a conditional build makes no sense (c) the absence of %bcond_xx is legit due to software not exercising xx at all
On Sat, Feb 25, 2023 at 7:23 AM Jan Engelhardt <jengelh@inai.de> wrote:
On Saturday 2023-02-25 11:22, Arjen de Korte wrote:
Would it be possible to have rpmlint check for these dependencies and emit a warning if the corresponding %bcond is not found in the specfile?
rpmlint cannot distinguish between
(a) xx is optional and the absence of %bcond_xx is unfortunate (b) the absence of %bcond_xx is legit due to package hard-requires xx and a conditional build makes no sense (c) the absence of %bcond_xx is legit due to software not exercising xx at all
Also, as a member of rpmlint upstream, even if it were possible, I don't want to see it there. If you want checks like that, use a tool actually *designed* for that. One such example is rpminspect[1]. Overloading rpmlint with all kinds of weird things isn't worth it. [1]: https://github.com/rpminspect -- 真実はいつも一つ！/ Always, there's only one truth!
participants (9)
-
Arjen de Korte -
Dominique Leuenberger -
Jan Engelhardt -
Martin Wilck -
Neal Gompa -
Olaf Hering -
pgajdos -
Richard Biener -
Thorsten Kukuk