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
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?
- if somebody added this %bcond to your packages, please accept them and forward them to Factory.
- if you are working on a package and have dependencies mentioned in the list, please consider to make your package configurable in this regard.
- 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.
- 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, 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?
- if somebody added this %bcond to your packages, please accept them and forward them to Factory.
- if you are working on a package and have dependencies mentioned in the list, please consider to make your package configurable in this regard.
- 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.
- 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!
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
https://en.opensuse.org/openSUSE:Package_Conditional_Build_Dependencies
Its a wiki, so we can expand the list, right?
Petr
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, 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
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
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
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
Citeren Thorsten Kukuk kukuk@suse.de:
What does this mean for you?
- if somebody added this %bcond to your packages, please accept them and forward them to Factory.
- if you are working on a package and have dependencies mentioned in the list, please consider to make your package configurable in this regard.
- 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.
- 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
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
-
Arjen de Korte -
Dominique Leuenberger -
Jan Engelhardt -
Martin Wilck -
Neal Gompa -
Olaf Hering -
pgajdos -
Richard Biener -
Thorsten Kukuk