Hi Folks,
We're gearing up to build the next minor release of CentOS Linux 8 so I thought now would be a good time to revisit the conversation we've been having about what to do with unshipped -devel packages. Just a reminder on a few guiding principles:
- The BaseOS, AppStream, and PowerTools repos in CentOS Linux are designed and composed to match Upstream as closely as possible, both in content and behavior
- Unshipped devel packages have no defined maintenance lifecycle in Upstream, and especially not in CentOS
- We know that some of these devel packages are essential to build applications that the CentOS (and probably EPEL) communities care about.
The problems we need to solve if we decide to ship these packages somewhere in a CentOS artifact:
- Communicate that these packages are provided as-is and are not meant for runtime dependencies
- Provide the packages in a form that is consumable for individuals and the EPEL community
I'd like to propose that we create a separate repository, disabled by default that is composed of the -devel packages that we care about, bundled in a module.
The name of this repository and the module is up for discussion, but I would like the naming to help with the communication that these are not for general consumption.
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping *everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
Looking forward to the discussion!
-- Brian Stinson CentOS Infra Team
On Wed, Nov 6, 2019, at 11:45, Trevor Hemsley wrote:
On 06/11/2019 17:35, Brian Stinson wrote:
I'd like to propose that we create a separate repository, disabled by default that is composed of the -devel packages that we care about, bundled in a module.
Good plan... except the module bit. Is that required?
Trevor
Some devel subpackages may be generated from distro modules (either in AppStream or PowerTools), that means that those packages would land in a blacklist. To make them installable they would need to be included in a module.
--Brian
El 6/11/19 a las 14:35, Brian Stinson escribió:
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping*everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
I would love to see *Everything*, but it could be problematic with modules like python36 (blacklisting all the python2 rpms) and python27 (blacklisting all the python3 rpms)
Pablo.
On 06/11/2019 18:44, Pablo Sebastián Greco wrote:
El 6/11/19 a las 14:35, Brian Stinson escribió:
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping*everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
I would love to see *Everything*, but it could be problematic with modules like python36 (blacklisting all the python2 rpms) and python27 (blacklisting all the python3 rpms)
we've got precidence here in the addons repo that was shipped in past versions, where content built but not shipped clearly upstream was avaialble.
at the very least, content coming from srpms that have a corrosponding binary in the other 3 repos should ship by default.
how much content are we talking about that comes from srpms that dont have a single component that ships in the main 3 repos ?
Also, i would leave this repo enabled. there isnt anything conflicting with the distro rpms here is there ?
regards
Am 06.11.19 um 21:00 schrieb Karanbir Singh:
On 06/11/2019 18:44, Pablo Sebastián Greco wrote:
El 6/11/19 a las 14:35, Brian Stinson escribió:
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping*everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
I would love to see *Everything*, but it could be problematic with modules like python36 (blacklisting all the python2 rpms) and python27 (blacklisting all the python3 rpms)
we've got precidence here in the addons repo that was shipped in past versions, where content built but not shipped clearly upstream was avaialble.
at the very least, content coming from srpms that have a corrosponding binary in the other 3 repos should ship by default.
how much content are we talking about that comes from srpms that dont have a single component that ships in the main 3 repos ?
Also, i would leave this repo enabled. there isnt anything conflicting with the distro rpms here is there ?
I think the repo name should be clearly communicate what it is, "addons" seems for me misleading. Its not only about -devel packages, for examples avahi-dnsconfd is build but unshipped. Therefore the name should communicate something like "build but not shipped and therefore unsupported".
-- Leon
On 06/11/2019 20:14, Leon Fauster via CentOS-devel wrote:
Am 06.11.19 um 21:00 schrieb Karanbir Singh:
On 06/11/2019 18:44, Pablo Sebastián Greco wrote:
El 6/11/19 a las 14:35, Brian Stinson escribió:
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping*everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
I would love to see *Everything*, but it could be problematic with modules like python36 (blacklisting all the python2 rpms) and python27 (blacklisting all the python3 rpms)
we've got precidence here in the addons repo that was shipped in past versions, where content built but not shipped clearly upstream was avaialble.
at the very least, content coming from srpms that have a corrosponding binary in the other 3 repos should ship by default.
how much content are we talking about that comes from srpms that dont have a single component that ships in the main 3 repos ?
Also, i would leave this repo enabled. there isnt anything conflicting with the distro rpms here is there ?
I think the repo name should be clearly communicate what it is, "addons" seems for me misleading. Its not only about -devel packages, for examples avahi-dnsconfd is build but unshipped. Therefore the name should communicate something like "build but not shipped and therefore unsupported".
to me, addons communicates just that, and has existed in the past - also, nothing in CentOS is 'supported'.
El 6/11/19 a las 17:18, Karanbir Singh escribió:
On 06/11/2019 20:14, Leon Fauster via CentOS-devel wrote:
Am 06.11.19 um 21:00 schrieb Karanbir Singh:
On 06/11/2019 18:44, Pablo Sebastián Greco wrote:
El 6/11/19 a las 14:35, Brian Stinson escribió:
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping*everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
I would love to see *Everything*, but it could be problematic with modules like python36 (blacklisting all the python2 rpms) and python27 (blacklisting all the python3 rpms)
we've got precidence here in the addons repo that was shipped in past versions, where content built but not shipped clearly upstream was avaialble.
at the very least, content coming from srpms that have a corrosponding binary in the other 3 repos should ship by default.
how much content are we talking about that comes from srpms that dont have a single component that ships in the main 3 repos ?
Also, i would leave this repo enabled. there isnt anything conflicting with the distro rpms here is there ?
I think the repo name should be clearly communicate what it is, "addons" seems for me misleading. Its not only about -devel packages, for examples avahi-dnsconfd is build but unshipped. Therefore the name should communicate something like "build but not shipped and therefore unsupported".
to me, addons communicates just that, and has existed in the past - also, nothing in CentOS is 'supported'.
Right, but normally things in CentOS are supported in RHEL, these packages don't fall into that category.
On Wed, Nov 6, 2019 at 3:26 PM Pablo Sebastián Greco pgreco@centosproject.org wrote:
Right, but normally things in CentOS are supported in RHEL, these packages don't fall into that category.
"quota" is supported. It's a critical component of "nfs-utils" and of various NFS tools. If quota is not supported, then as best I can tell RHEL will have to abandon support for NFS. If NFS is abandoned, please let me know. I want to bring popcorn and a a soda for for *that* feature release announcement.
On Thu, 7 Nov 2019 at 20:49, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Wed, Nov 6, 2019 at 3:26 PM Pablo Sebastián Greco pgreco@centosproject.org wrote:
Right, but normally things in CentOS are supported in RHEL, these packages don't fall into that category.
"quota" is supported. It's a critical component of "nfs-utils" and of various NFS tools. If quota is not supported, then as best I can tell RHEL will have to abandon support for NFS. If NFS is abandoned, please let me know. I want to bring popcorn and a a soda for for *that* feature release announcement.
English Compiler Warning:
The word "supported" is an overloaded operator and you are trying to use your version for all versions of it.
The package quota is 'supported' by Red Hat for use with certain tools that are shipped. While they have expressed that is what their support policies covered, by shipping the -devel they were also getting tickets on why does this not work with this compilation, and fix this bug in this header file. In order to clarify exactly what they are going to cover with their technical support, they decided to stop shipping things which lead to tickets they did not cover.
You are using the word support in a slightly different manner where support means it needs to be there for a process to work. There is also defining support in that the source code 'supports' the building of other things with it. Both of those are outside of the meaning that Red Hat is using the word.
I expect that if this were Chinese, German or French each of those different meanings would have completely different words which would make confusion less likely. However, English likes to use one word for many things hoping that people will 'just know' the differences.
On Wed, Nov 6, 2019, at 14:00, Karanbir Singh wrote:
On 06/11/2019 18:44, Pablo Sebastián Greco wrote:
El 6/11/19 a las 14:35, Brian Stinson escribió:
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping*everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
I would love to see *Everything*, but it could be problematic with modules like python36 (blacklisting all the python2 rpms) and python27 (blacklisting all the python3 rpms)
we've got precidence here in the addons repo that was shipped in past versions, where content built but not shipped clearly upstream was avaialble.
at the very least, content coming from srpms that have a corrosponding binary in the other 3 repos should ship by default.
how much content are we talking about that comes from srpms that dont have a single component that ships in the main 3 repos ?
Also, i would leave this repo enabled. there isnt anything conflicting with the distro rpms here is there ?
regards
A couple of points about these packages. They're used in *only* to build the distro, Red Hat has very little to do with these packages after the distro is built and shipped. Any package in this category can change/move/upgrade/downgrade/disappear/become supported however they like or not change at all. And there's not a good way for us to know what the future looks like for an individual package in this category.
Some napkin math, using x86_64 as the subject arch, there are on the order of 1000 source packages that have a package or subpackage in this category. About 400 of those SRPMs are exclusive to this category (that is, there is nothing shipped in-distro).
I'd be very concerned about shipping this repo enabled by default because we don't want to encourage buildtime deps on this content, and I'd really like to limit the content to things that the community actually needs from the distro which is why I wanted to maintain lists. Some of this content may make more sense to be rebuilt in a SIG or elsewhere, but there's no way to know that if we enable the firehose.
On Wed, 6 Nov 2019 at 15:01, Karanbir Singh kbsingh@centos.org wrote:
On 06/11/2019 18:44, Pablo Sebastián Greco wrote:
El 6/11/19 a las 14:35, Brian Stinson escribió:
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping*everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
I would love to see *Everything*, but it could be problematic with modules like python36 (blacklisting all the python2 rpms) and python27 (blacklisting all the python3 rpms)
we've got precidence here in the addons repo that was shipped in past versions, where content built but not shipped clearly upstream was avaialble.
at the very least, content coming from srpms that have a corrosponding binary in the other 3 repos should ship by default.
how much content are we talking about that comes from srpms that dont have a single component that ships in the main 3 repos ?
Also, i would leave this repo enabled. there isnt anything conflicting with the distro rpms here is there ?
Actually there will be. Because a module blacklists things and does not want those unshipped items installed while it is installed. You thus have to create a full module which contains all the previous content and the previously blacklisted content.
So let us say the python27 module ships python27-foo but does not ship python27-foo-devel. You need to create a new module with all of python27, python27-foo so you can have python27-foo-devel. [This is because the Name-EpochVersionRelease between the python27-foo and python27-foo-devel need to match to install.. and modular builds get unique names.
You can't have a seperate module with just python27-foo-devel in it because the first module has a filter which will 'conflict' at the modular level. This means this addon repo will have to have a 'conflicting' python27.
[Because any update within a module means a complete new module build, you are either going to respin this BatteriesNotIncluded repo for every update, or just updating say a Python27 or a Python36 or a FreeIPA etc submodule.]
On Wed, Nov 6, 2019, at 8:01 PM, Stephen John Smoogen wrote:
On Wed, 6 Nov 2019 at 15:01, Karanbir Singh kbsingh@centos.org wrote:
On 06/11/2019 18:44, Pablo Sebastián Greco wrote:
El 6/11/19 a las 14:35, Brian Stinson escribió:
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping*everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
I would love to see *Everything*, but it could be problematic with modules like python36 (blacklisting all the python2 rpms) and python27 (blacklisting all the python3 rpms)
we've got precidence here in the addons repo that was shipped in past versions, where content built but not shipped clearly upstream was avaialble.
at the very least, content coming from srpms that have a corrosponding binary in the other 3 repos should ship by default.
how much content are we talking about that comes from srpms that dont have a single component that ships in the main 3 repos ?
Also, i would leave this repo enabled. there isnt anything conflicting with the distro rpms here is there ?
Actually there will be. Because a module blacklists things and does not want those unshipped items installed while it is installed. You thus have to create a full module which contains all the previous content and the previously blacklisted content.
Can't you just scrape the built but not shipped artifacts from the build system, and synthesize the repo/module data? Does it actually have to be a separately built module?
So let us say the python27 module ships python27-foo but does not ship python27-foo-devel. You need to create a new module with all of python27, python27-foo so you can have python27-foo-devel. [This is because the Name-EpochVersionRelease between the python27-foo and python27-foo-devel need to match to install.. and modular builds get unique names.
Seems like this constraint would be satisfied with synthesizing module data.
You can't have a seperate module with just python27-foo-devel in it because the first module has a filter which will 'conflict' at the modular level. This means this addon repo will have to have a 'conflicting' python27.
Is this because of the NEVR constraint or something else?
V/r, James Cassell
[Because any update within a module means a complete new module build, you are either going to respin this BatteriesNotIncluded repo for every update, or just updating say a Python27 or a Python36 or a FreeIPA etc submodule.]
On Wed, Nov 6, 2019, at 20:31, James Cassell wrote:
On Wed, Nov 6, 2019, at 8:01 PM, Stephen John Smoogen wrote:
On Wed, 6 Nov 2019 at 15:01, Karanbir Singh kbsingh@centos.org wrote:
On 06/11/2019 18:44, Pablo Sebastián Greco wrote:
El 6/11/19 a las 14:35, Brian Stinson escribió:
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping*everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
I would love to see *Everything*, but it could be problematic with modules like python36 (blacklisting all the python2 rpms) and python27 (blacklisting all the python3 rpms)
we've got precidence here in the addons repo that was shipped in past versions, where content built but not shipped clearly upstream was avaialble.
at the very least, content coming from srpms that have a corrosponding binary in the other 3 repos should ship by default.
how much content are we talking about that comes from srpms that dont have a single component that ships in the main 3 repos ?
Also, i would leave this repo enabled. there isnt anything conflicting with the distro rpms here is there ?
Actually there will be. Because a module blacklists things and does not want those unshipped items installed while it is installed. You thus have to create a full module which contains all the previous content and the previously blacklisted content.
Can't you just scrape the built but not shipped artifacts from the build system, and synthesize the repo/module data? Does it actually have to be a separately built module?
So let us say the python27 module ships python27-foo but does not ship python27-foo-devel. You need to create a new module with all of python27, python27-foo so you can have python27-foo-devel. [This is because the Name-EpochVersionRelease between the python27-foo and python27-foo-devel need to match to install.. and modular builds get unique names.
Seems like this constraint would be satisfied with synthesizing module data.
You can't have a seperate module with just python27-foo-devel in it because the first module has a filter which will 'conflict' at the modular level. This means this addon repo will have to have a 'conflicting' python27.
Is this because of the NEVR constraint or something else?
V/r, James Cassell
[Because any update within a module means a complete new module build, you are either going to respin this BatteriesNotIncluded repo for every update, or just updating say a Python27 or a Python36 or a FreeIPA etc submodule.]
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Anything we do needs to be an output from the build/compose tooling that we use to produce the distro. We're trying to keep the repodata hacking to a minimum.
On Wed, 6 Nov 2019 at 21:31, James Cassell fedoraproject@cyberpear.com wrote:
On Wed, Nov 6, 2019, at 8:01 PM, Stephen John Smoogen wrote:
On Wed, 6 Nov 2019 at 15:01, Karanbir Singh kbsingh@centos.org wrote:
On 06/11/2019 18:44, Pablo Sebastián Greco wrote:
El 6/11/19 a las 14:35, Brian Stinson escribió:
I'd also like to discuss how we populate this repo/module. It would be easiest to just dump every unshipped package in and move on, but that doesn't help us track which of these packages are truly important outside of building the distro. Shipping*everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
I would love to see *Everything*, but it could be problematic with modules like python36 (blacklisting all the python2 rpms) and python27 (blacklisting all the python3 rpms)
we've got precidence here in the addons repo that was shipped in past versions, where content built but not shipped clearly upstream was avaialble.
at the very least, content coming from srpms that have a corrosponding binary in the other 3 repos should ship by default.
how much content are we talking about that comes from srpms that dont have a single component that ships in the main 3 repos ?
Also, i would leave this repo enabled. there isnt anything conflicting with the distro rpms here is there ?
Actually there will be. Because a module blacklists things and does not want those unshipped items installed while it is installed. You thus have to create a full module which contains all the previous content and the previously blacklisted content.
Can't you just scrape the built but not shipped artifacts from the build system, and synthesize the repo/module data? Does it actually have to be a separately built module?
It depends on what the build tools allow for. A lot of this is machine code built which means a scrape tends to need a lot of hand holding to keep up with X.1947012340 is now X.1948012441 after an update because both will be there in the repo (I think this is because some software needs to have all the variants in between for updates but I am probably confusing it with something else)
So let us say the python27 module ships python27-foo but does not ship python27-foo-devel. You need to create a new module with all of python27, python27-foo so you can have python27-foo-devel. [This is because the Name-EpochVersionRelease between the python27-foo and python27-foo-devel need to match to install.. and modular builds get unique names.
Seems like this constraint would be satisfied with synthesizing module data.
If someone wants to write the tools to do that.. I think we would all appreciate it.
You can't have a seperate module with just python27-foo-devel in it because the first module has a filter which will 'conflict' at the modular level. This means this addon repo will have to have a 'conflicting' python27.
Is this because of the NEVR constraint or something else?
When I was playing with this in the RHEL-8 Beta it was due to how modules 'filter' what they will allow to be installed. Various modules had filters which would block various packages, and the only way to get them installed was to switch to an alternate module which had those items in it. You have to do alternate modules for this because for like the perl which ships 5.24 and 5.26.. the package names are the same and some of the -devel from those will only work with the 5.24 or 5.26. [Same if they ship alternate ruby/python38/rust/etc]
Am 06.11.19 um 18:35 schrieb Brian Stinson: <snip>
The problems we need to solve if we decide to ship these packages somewhere in a CentOS artifact:
- Communicate that these packages are provided as-is and are not meant for runtime dependencies
Is a separate repo with a expressive name and corresponding wiki page not enough (like CR)?
- Provide the packages in a form that is consumable for individuals and the EPEL community
I'd like to propose that we create a separate repository, disabled by default that is composed of the -devel packages that we care about, bundled in a module.\
Why modules? What problem gets addressed? Why not just dropping the unshipped build output into a separate repo?
-- Leon
On Wed, Nov 6, 2019, at 14:34, Leon Fauster via CentOS-devel wrote:
Am 06.11.19 um 18:35 schrieb Brian Stinson:
<snip> > > The problems we need to solve if we decide to ship these packages somewhere in > a CentOS artifact: > > - Communicate that these packages are provided as-is and are not meant for > runtime dependencies
Is a separate repo with a expressive name and corresponding wiki page not enough (like CR)?
- Provide the packages in a form that is consumable for individuals and the EPEL community
I'd like to propose that we create a separate repository, disabled by default that is composed of the -devel packages that we care about, bundled in a module.\
Why modules? What problem gets addressed? Why not just dropping the unshipped build output into a separate repo?
-- Leon _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Any unshipped package that is the member of a module is part of a blacklist in the distro repodata. If we don't bundle these into a module, there's no way for your workstation to know that this package is intended to be installable.
Am 06.11.19 um 21:43 schrieb Brian Stinson:
On Wed, Nov 6, 2019, at 14:34, Leon Fauster via CentOS-devel wrote:
Am 06.11.19 um 18:35 schrieb Brian Stinson:
<snip> > > The problems we need to solve if we decide to ship these packages somewhere in > a CentOS artifact: > > - Communicate that these packages are provided as-is and are not meant for > runtime dependencies
Is a separate repo with a expressive name and corresponding wiki page not enough (like CR)?
- Provide the packages in a form that is consumable for individuals and the EPEL community
I'd like to propose that we create a separate repository, disabled by default that is composed of the -devel packages that we care about, bundled in a module.\
Why modules? What problem gets addressed? Why not just dropping the unshipped build output into a separate repo?
Any unshipped package that is the member of a module is part of a blacklist in the distro repodata. If we don't bundle these into a module, there's no way for your workstation to know that this package is intended to be installable.
Thanks for clarifing this!
-- Leon
On Wed, Nov 6, 2019 at 12:37 PM Brian Stinson brian@bstinson.com wrote:
Hi Folks,
We're gearing up to build the next minor release of CentOS Linux 8 so I thought now would be a good time to revisit the conversation we've been having about what to do with unshipped -devel packages. Just a reminder on a few guiding principles:
The BaseOS, AppStream, and PowerTools repos in CentOS Linux are designed and composed to match Upstream as closely as possible, both in content and behavior
Unshipped devel packages have no defined maintenance lifecycle in Upstream, and especially not in CentOS
Based on the source for "quota", these "devel" packages are built along with the binary RPMs. It takes extra work to exclude them from publication along with the binary RPMs. If Red Hat is publishing the SRPM, and building the RPMs, it is capricious to exclude the "devel" packages. As best I've seen over more than 20 years, they have never pulled this stunt before.
- We know that some of these devel packages are essential to build applications that the CentOS (and probably EPEL) communities care about.
The problems we need to solve if we decide to ship these packages somewhere in a CentOS artifact:
Communicate that these packages are provided as-is and are not meant for runtime dependencies
Provide the packages in a form that is consumable for individuals and the EPEL community
Well, yes. A polite note that Red Hat elected to be really silly about this one should serve quite well.
I'd like to propose that we create a separate repository, disabled by default that is composed of the -devel packages that we care about, bundled in a module.
The name of this repository and the module is up for discussion, but I would like the naming to help with the communication that these are not for general consumption.
Please don't. The current multiplicity of streams from upstream is, in my observation. pretty foolish. There is no separate stream to put the SRPM ijn, because the published SRPM bullds the quota-devel package. (I checked as part of resolving the quota-devel dependency for Samba with the full domain controller enabled for RHEL 8). The software license for the quota package is GPLv2, there is no problem publishing the devel package.
I'd also like to discuss how we populate this repo/module. It would be
Just leave it in the mainliine repos. In this very small way they will differ from RHEL. But this is, I think, the only case I have ever seen RHEL refuse to publish the accompanying devel package with a binary package. It's not behavior to emulate.
easiest to just dump every unshipped package in and move on, but that
This is *not* an unshipped package. This is a package that is shipped, it's necessary for compiling Samba with domain-controller enabled, it's included in the upstream Fedora builds, it's compiled automatically along with the binary package, and it was deliberately excluced.
doesn't help us track which of these packages are truly important outside of building the distro. Shipping *everything* also represents a larger content set to manage if lifecycle issues come up in the future. An alternative would be to store this definition in git (we'll need to do that anyways), and allow folks to make pull requests to include new content, shipping this as a separate repo would let us spin updates on demand.
Well, yes. If you'r4e going to include development libraries at all, it's going to be a larger set of repositories. But picking and choosing which to ship binaries, and which to exclude include files for this way is new behavior and quite capricious. It makes me quesiton what the motive is. And as much as I hate to think it, I think it's to hinder Samba domain controller deploymen in favor of FreeIPA, which seems to have become a sore point.
And no. There is no need, nor exuse, for module wrapping something that is a critical system component. Fedora is in the midst of some very heated discussions about the benefits, and lack of benefits, of modules, and interjecting them into this kind of already built, the SRPM already builds the devel package, discussion is distracting clutter.
Hi CentOS devs. Was there any resolution to this issue?
I'm trying to rebuild krb5 but am running into trouble as libss-devel is not available in 8.
Any help or advice appreciated.
On Tue, Feb 4, 2020, at 18:04, Tane Adam wrote:
Hi CentOS devs. Was there any resolution to this issue?
I'm trying to rebuild krb5 but am running into trouble as libss-devel is not available in 8.
Any help or advice appreciated.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Do you have a bug open on bugs.centos.org for libss-devel? If not, would you mind filing one against the CentOS-8 project?
We're still gathering up bug reports but the plan is to dump things like this into a separate repository on a case-by-case basis. More details to come in an announcement here on centos-devel.
--Brian
On Tue, Feb 4, 2020 at 7:11 PM Brian Stinson brian@bstinson.com wrote:
Do you have a bug open on bugs.centos.org for libss-devel? If not, would you mind filing one against the CentOS-8 project?
We're still gathering up bug reports but the plan is to dump things like this into a separate repository on a case-by-case basis. More details to come in an announcement here on centos-devel.
--Brian
Please link newly submitted requests to bug #16492.
Akemi
https://bugs.centos.org/view.php?id=17011 I'm not sure how link the issue to 16492. Thanks.
On Wed, Feb 5, 2020 at 8:50 AM Akemi Yagi amyagi@gmail.com wrote:
On Tue, Feb 4, 2020 at 7:11 PM Brian Stinson brian@bstinson.com wrote:
Do you have a bug open on bugs.centos.org for libss-devel? If not,
would you mind filing one against the CentOS-8 project?
We're still gathering up bug reports but the plan is to dump things like
this into a separate repository on a case-by-case basis. More details to come in an announcement here on centos-devel.
--Brian
Please link newly submitted requests to bug #16492.
Akemi _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
I've also created a new bug for all the KDE related build failures https://bugs.centos.org/view.php?id=17032 I don't see any way for me to link it to 16492 Could someone with the correct permissions do that for me?
Thanks Troy
On Wed, Feb 5, 2020 at 10:40 AM Tane Adam tadam@scalecomputing.com wrote:
https://bugs.centos.org/view.php?id=17011 I'm not sure how link the issue to 16492. Thanks.
On Wed, Feb 5, 2020 at 8:50 AM Akemi Yagi amyagi@gmail.com wrote:
On Tue, Feb 4, 2020 at 7:11 PM Brian Stinson brian@bstinson.com wrote:
Do you have a bug open on bugs.centos.org for libss-devel? If not,
would you mind filing one against the CentOS-8 project?
We're still gathering up bug reports but the plan is to dump things
like this into a separate repository on a case-by-case basis. More details to come in an announcement here on centos-devel.
--Brian
Please link newly submitted requests to bug #16492.
Akemi
Hi Troy,
Troy Dawson tdawson@redhat.com hat am 10. Februar 2020 um 16:21 geschrieben:
I've also created a new bug for all the KDE related build failures https://bugs.centos.org/view.php?id=17032 I don't see any way for me to link it to 16492 Could someone with the correct permissions do that for me?
done
all the best Christoph -- Christoph Galuschka CentOS-QA member | IRC: tigalch
On Mon, Feb 10, 2020 at 04:24:48PM +0100, Christoph Galuschka wrote:
Hi Troy,
Troy Dawson tdawson@redhat.com hat am 10. Februar 2020 um 16:21 geschrieben:
I've also created a new bug for all the KDE related build failures https://bugs.centos.org/view.php?id=17032 I don't see any way for me to link it to 16492 Could someone with the correct permissions do that for me?
done
Could you do the same for
https://bugs.centos.org/view.php?id=17081
?
Thank you,
On Mon, Feb 24, 2020 at 1:55 AM Jan Pazdziora jpazdziora@redhat.com wrote:
On Mon, Feb 10, 2020 at 04:24:48PM +0100, Christoph Galuschka wrote:
Hi Troy,
Troy Dawson tdawson@redhat.com hat am 10. Februar 2020 um 16:21 geschrieben:
I've also created a new bug for all the KDE related build failures https://bugs.centos.org/view.php?id=17032 I don't see any way for me to link it to 16492 Could someone with the correct permissions do that for me?
done
Could you do the same for
https://bugs.centos.org/view.php?id=17081?
Thank you,
Done
Hi, I opened https://bugs.centos.org/view.php?id=17092 due to missing libvirt-glib-devel. We need it in CentOS VIrt SIG for building libvirt-dbus within Advanced Virtualization. Can you please handle? Thanks,
Il giorno lun 24 feb 2020 alle ore 16:17 Troy Dawson tdawson@redhat.com ha scritto:
On Mon, Feb 24, 2020 at 1:55 AM Jan Pazdziora jpazdziora@redhat.com wrote:
On Mon, Feb 10, 2020 at 04:24:48PM +0100, Christoph Galuschka wrote:
Hi Troy,
Troy Dawson tdawson@redhat.com hat am 10. Februar 2020 um 16:21
geschrieben:
I've also created a new bug for all the KDE related build failures https://bugs.centos.org/view.php?id=17032 I don't see any way for me to link it to 16492 Could someone with the correct permissions do that for me?
done
Could you do the same for
https://bugs.centos.org/view.php?id=17081?
Thank you,
Done
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Am 05.02.20 um 04:10 schrieb Brian Stinson:
On Tue, Feb 4, 2020, at 18:04, Tane Adam wrote:
Hi CentOS devs. Was there any resolution to this issue?
I'm trying to rebuild krb5 but am running into trouble as libss-devel is not available in 8.
Any help or advice appreciated.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Do you have a bug open on bugs.centos.org for libss-devel? If not, would you mind filing one against the CentOS-8 project?
We're still gathering up bug reports but the plan is to dump things like this into a separate repository on a case-by-case basis. More details to come in an announcement here on centos-devel.
While compiling stuff here I already have this list of missing packages (more are coming because some additional stuff are still in the build pipe).
libXvMC-devel libbluray-devel rest-devel avahi-glib-devel avahi-gobject-devel avahi-ui-devel totem-pl-parser-devel libdmapsharing-devel
Should this really be done on a case-by-case basis? Why not providing the separated repo with all missing assets? A keep it simple approach? Upstream do not provide it because they do not give support for such parts of RHEL. CentOS does not give any support anyway, so why holding this back? Or is upstream slowing this down?
-- Leon
On Tue, Feb 4, 2020 at 7:05 PM Tane Adam tadam@scalecomputing.com wrote:
Hi CentOS devs. Was there any resolution to this issue?
I'm trying to rebuild krb5 but am running into trouble as libss-devel is not available in 8.
Any help or advice appreciated.
I've run into this with quota-devel, which Red Hat doesn't ship with RHEL 9, either. The upstream decision at Red Hat not to publish devel packages used to build RPMs which they do publish is.... Well, it's a reason not to sign a support contract if we have to build things ourselves because Red Hat specifically elected not to include packages that they build as part of open source tools and rely on, internally.
-
Akemi Yagi -
Brian Stinson -
Christoph Galuschka -
James Cassell -
Jan Pazdziora -
Karanbir Singh -
Leon Fauster -
Nico Kadel-Garcia -
Pablo Sebastián Greco -
Sandro Bonazzola -
Stephen John Smoogen -
Tane Adam -
Trevor Hemsley -
Troy Dawson