To implement some Fedora 25 changes (split NSS (Name Service Switch) subpackages, libcrypt without NSS (Mozilla Network Security Services) library depdencies), I added additional subpackages to the glibc packages, namely:
- libcrypt - libcrypt-nss - nss_db - nss_hesiod - nss_nis
The expectation is that libgcrypt-nss is installed by default, and system administrators may opt to install libcrypt (with the internal algorithm implementations instead). libcrypt and libcrypt-nss both provide the soname-based RPM dependencies required by applications which need password hashing.
In contrast, nss_db, nss_hesiod, nss_nis are expected to be installed by system administrators who need the specific functionality. They are not installed by default. (nss_files and nss_dns remain part of the main glibc package because their use is pretty much required by all installations.)
The background for these changes is twofold: We want to reduce minimal image size (also the gains a very small), and we want to pave the road towards alternative implementations (based on OpenSSL for libcrypt, and based on libtirpc for nss_nis).
Thanks, Florian
On Sunday, July 24, 2016 5:15:51 PM CDT Florian Weimer wrote:
To implement some Fedora 25 changes (split NSS (Name Service Switch) subpackages, libcrypt without NSS (Mozilla Network Security Services) library depdencies), I added additional subpackages to the glibc packages, namely:
- libcrypt
- libcrypt-nss
- nss_db
- nss_hesiod
- nss_nis
The expectation is that libgcrypt-nss is installed by default, and system administrators may opt to install libcrypt (with the internal algorithm implementations instead). libcrypt and libcrypt-nss both provide the soname-based RPM dependencies required by applications which need password hashing.
In contrast, nss_db, nss_hesiod, nss_nis are expected to be installed by system administrators who need the specific functionality. They are not installed by default. (nss_files and nss_dns remain part of the main glibc package because their use is pretty much required by all installations.)
The background for these changes is twofold: We want to reduce minimal image size (also the gains a very small), and we want to pave the road towards alternative implementations (based on OpenSSL for libcrypt, and based on libtirpc for nss_nis).
Thanks, Florian
Bodhi has zero support for Reccomends and Suggests, we can not push out updates with them. The use of Rich dependencies is not allowed. See [1] for more details
Dennis
[1] https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro... sort=date
On Wednesday, 10 August 2016 at 10:52, Dennis Gilmore wrote:
On Sunday, July 24, 2016 5:15:51 PM CDT Florian Weimer wrote:
To implement some Fedora 25 changes (split NSS (Name Service Switch) subpackages, libcrypt without NSS (Mozilla Network Security Services) library depdencies), I added additional subpackages to the glibc packages, namely:
- libcrypt
- libcrypt-nss
- nss_db
- nss_hesiod
- nss_nis
The expectation is that libgcrypt-nss is installed by default, and system administrators may opt to install libcrypt (with the internal algorithm implementations instead). libcrypt and libcrypt-nss both provide the soname-based RPM dependencies required by applications which need password hashing.
In contrast, nss_db, nss_hesiod, nss_nis are expected to be installed by system administrators who need the specific functionality. They are not installed by default. (nss_files and nss_dns remain part of the main glibc package because their use is pretty much required by all installations.)
The background for these changes is twofold: We want to reduce minimal image size (also the gains a very small), and we want to pave the road towards alternative implementations (based on OpenSSL for libcrypt, and based on libtirpc for nss_nis).
Bodhi has zero support for Reccomends and Suggests, we can not push out updates with them. The use of Rich dependencies is not allowed. See [1] for more details
[1] https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro...
From what I can see, glibc.spec doesn't contain any rich dependencies (i.e. booleans) in Requires: or Recommends:. Do you have a specific issue with current glibc package?
Regards, Dominik
On 08/10/2016 11:47 AM, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 10 August 2016 at 10:52, Dennis Gilmore wrote:
On Sunday, July 24, 2016 5:15:51 PM CDT Florian Weimer wrote:
The background for these changes is twofold: We want to reduce minimal image size (also the gains a very small), and we want to pave the road towards alternative implementations (based on OpenSSL for libcrypt, and based on libtirpc for nss_nis).
Bodhi has zero support for Reccomends and Suggests, we can not push out updates with them. The use of Rich dependencies is not allowed. See [1] for more details
[1] https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro...
From what I can see, glibc.spec doesn't contain any rich dependencies (i.e. booleans) in Requires: or Recommends:. Do you have a specific issue with current glibc package?
My suspicion at this point is that the past FPC/Fesco guidelines wee wrong, and the present tooling restriction is not just about rich/Boolean dependencies, but also about weak dependencies.
Zero support for weak dependencies would actually be okay, sort of. The problem is that something treats the Recommends: as a Requires:, like yum does (bug 1360781).
Florian
On Wed, 10 Aug 2016 12:56:47 +0200 Florian Weimer fweimer@redhat.com wrote:
My suspicion at this point is that the past FPC/Fesco guidelines wee wrong, and the present tooling restriction is not just about rich/Boolean dependencies, but also about weak dependencies.
Could be.
Zero support for weak dependencies would actually be okay, sort of. The problem is that something treats the Recommends: as a Requires:, like yum does (bug 1360781).
Yeah, so we have 2 paths here:
1. pungi does the rawhide and branched composes. These are running on Fedora instances. I think it also uses createrepo_c. These composes do have the rich/weak/etc deps.
2. bodhi does the updates / updates-testing repos. Currently this is running on a rhel7 instance. It uses mash and mash uses createrepo which uses yum. In this case the rich deps actually break the compose and it won't work with them in the updates set, and weak deps are likely treated the way yum would since createrepo uses yum.
One short term thing we can try out is moving the bodhi instance to Fedora24 and see if the newer rpm can handle things better. I'm not sure if this will work fully, but we can give it a try and see.
If that fails we could possibly wait for the https://fedoraproject.org/wiki/Changes/KojiSignedRepos change to finally land, as those will be generated on Fedora builders.
It's unclear to me if we need just a newer rpm or need to switch away from createrepo. If some folks wanted to do some testing that would be great. ;) Just make a repo of packages with weak/rich/whatever deps and build it on rhel7 and fedora24 and see if the correct metadata is there and then again with createrepo_c.
kevin
On Wed, Aug 10, 2016 at 2:40 PM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 10 Aug 2016 12:56:47 +0200 Florian Weimer fweimer@redhat.com wrote:
My suspicion at this point is that the past FPC/Fesco guidelines wee wrong, and the present tooling restriction is not just about rich/Boolean dependencies, but also about weak dependencies.
Could be.
Zero support for weak dependencies would actually be okay, sort of. The problem is that something treats the Recommends: as a Requires:, like yum does (bug 1360781).
Yeah, so we have 2 paths here:
- pungi does the rawhide and branched composes. These are running on
Fedora instances. I think it also uses createrepo_c. These composes do have the rich/weak/etc deps.
- bodhi does the updates / updates-testing repos. Currently this is
running on a rhel7 instance. It uses mash and mash uses createrepo which uses yum. In this case the rich deps actually break the compose and it won't work with them in the updates set, and weak deps are likely treated the way yum would since createrepo uses yum.
I remember writing a patch for Mash that enabled createrepo_c support. [1]
Maybe it's time to cleanup that patch, get it tested, and move it forward.
[1] https://pagure.io/fork/parasense/mash/c/80d55f0b15345d2f8893b303731a144e6be4...
One short term thing we can try out is moving the bodhi instance to Fedora24 and see if the newer rpm can handle things better. I'm not sure if this will work fully, but we can give it a try and see.
If that fails we could possibly wait for the https://fedoraproject.org/wiki/Changes/KojiSignedRepos change to finally land, as those will be generated on Fedora builders.
It's unclear to me if we need just a newer rpm or need to switch away from createrepo. If some folks wanted to do some testing that would be great. ;) Just make a repo of packages with weak/rich/whatever deps and build it on rhel7 and fedora24 and see if the correct metadata is there and then again with createrepo_c.
kevin
-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
So, I misunderstood this issue. (I'll blame the cold medicine)
In this case the problem is that arm images are made with appliance-creator from appliance-tools. That in turn uses livecd-tools (the old way we used to make live media but no longer do in favor of livemedia-creator from lorax).
So, to fix this we either need to:
* Change how we make arm images to something that uses dnf.
* Fix appliance-creator to use livemedia-tools instead of livecd-tools.
* Change how we do things in glibc.
As a side note, I did create a bodhi-backend on Fedora 24 and pushed fedora-25 updates-testing with it. It indeed seems to have recommends in it now (can someone check?). But that doesn't help this case at all, since appliance-creator doesn't do the right thing, and glibc isn't even in updates-testing anyhow.
kevin
So, I misunderstood this issue. (I'll blame the cold medicine)
In this case the problem is that arm images are made with appliance-creator from appliance-tools. That in turn uses livecd-tools (the old way we used to make live media but no longer do in favor of livemedia-creator from lorax).
So, to fix this we either need to:
Change how we make arm images to something that uses dnf.
Fix appliance-creator to use livemedia-tools instead of livecd-tools.
No no no no.... appliance-tools just needs to be taken out the back and shot!
- Change how we do things in glibc.
Actually the real fix to this is to move to lorax/live-media-creator. This needs virt on ARM so is currently blocking on the moonshot chassis, plus a few other fixes around ARMv7 virt on aarch64 which I've been slowly moving forward. We might be able to do thing on a mustang device. I'll try to spend some time testing it tomorrow/monday to see if we could move this forward quicker.
As a side note, I did create a bodhi-backend on Fedora 24 and pushed fedora-25 updates-testing with it. It indeed seems to have recommends in it now (can someone check?). But that doesn't help this case at all, since appliance-creator doesn't do the right thing, and glibc isn't even in updates-testing anyhow.
kevin
-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
-
Dennis Gilmore -
Dominik 'Rathann' Mierzejewski -
Florian Weimer -
Jon -
Kevin Fenzi -
Peter Robinson