Bug 1512213
Summary: | Move header file gdm-pam-extensions.h to separate package with minimal dependencies | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Lukas Slebodnik <lslebodn> | ||||
Component: | gdm | Assignee: | Ray Strode [halfline] <rstrode> | ||||
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.5 | CC: | alexl, bgollahe, caillon+fedoraproject, extras-qa, gnome-sig, john.j5live, mboisver, mclasen, nobody+bgollahe, rhughes, rstrode, tpelka | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | gdm-3.26.2.1-3.el7 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | 1512212 | Environment: | |||||
Last Closed: | 2018-04-10 13:07:25 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 1512212 | ||||||
Bug Blocks: | 1507614 | ||||||
Attachments: |
|
Description
Lukas Slebodnik
2017-11-11 16:17:44 UTC
There are less packages installed in rhel7 then in fedora 27 but it is still huge disadvantage for compilation of file which depends only on glibc and pam. sh# yum install 'pkgconfig(gdm-pam-extensions)' Loaded plugins: ovl Resolving Dependencies --> Running transaction check ---> Package gdm-devel.x86_64 1:3.26.2.1-1.el7 will be installed --> Processing Dependency: gdm(x86-64) = 1:3.26.2.1-1.el7 for package: 1:gdm-devel-3.26.2.1-1.el7.x86_64 //snip xml-common noarch 0.6.3-39.el7 RHEL-7.5-x86_64-main 26 k xorg-x11-server-utils x86_64 7.7-20.el7 RHEL-7.5-x86_64-main 178 k xorg-x11-xauth x86_64 1:1.0.9-1.el7 RHEL-7.5-x86_64-main 30 k xorg-x11-xinit x86_64 1.3.4-2.el7 RHEL-7.5-x86_64-main 59 k xorg-x11-xkb-utils x86_64 7.7-12.el7 RHEL-7.5-x86_64-main 103 k zenity x86_64 3.22.0-1.el7 RHEL-7.5-x86_64-main 744 k Transaction Summary ================================================================================ Install 1 Package (+253 Dependent packages) Total download size: 199 M Installed size: 662 M BTW it adds 220 build dependencies for sssd + 0 runtime dependencies. Expected result is 1 additional build dependency for sssd (because sssd already depends on pam-devel and glibc-headers So the approach we ended up with was decided on in bug 1413900 comment 8 and bug 1413900 comment 9. As you point out the current approach doesn't add any runtime dependencies, and I don't think it adds any build loops, so it's not actually, practically speaking, a real problem is it? i don't really want to create new upstream module, and add a whole new package to rhel for this. That's a lot of overhead for a file with a few convenience macros in it. If the build dependencies are actually an issue, can sssd just copy the header file in tree ? Alternatively, I guess I could create a new subpackage, %package pam-extensions Summary: macros for developing pam extensions that GDM supports Group: Development/Libraries Requires: pam-devel And not have an explict Requires: %{name}%{?_isa} = %{epoch}:%{version}-%{release} for the subpackage. I think that would eliminate the build deps, but it might make rpmdiff balk. I'm not sure. so three possibilities: 1) new module, new package, maitai process, etc 2) sssd copies header in tree 3) new subpackage I'm okay with 2 or 3, but you'll have to convince me harder for 1. Thoughts? (In reply to Ray Strode [halfline] from comment #4) > So the approach we ended up with was decided on in bug 1413900 comment 8 and > bug 1413900 comment 9. > > As you point out the current approach doesn't add any runtime dependencies, > and I don't think it adds any build loops, so it's not actually, practically > speaking, a real problem is it? > > i don't really want to create new upstream module, and add a whole new > package to rhel for this. That's a lot of overhead for a file with a few > convenience macros in it. If the build dependencies are actually an issue, > can sssd just copy the header file in tree ? > > Alternatively, I guess I could create a new subpackage, > > %package pam-extensions > Summary: macros for developing pam extensions that GDM supports > Group: Development/Libraries > Requires: pam-devel > > And not have an explict > > Requires: %{name}%{?_isa} = %{epoch}:%{version}-%{release} What would be purpose of this requires? Because it will if gdm-pam-extensions will depend on gdm than it would still pull many x11/wayland related dependencies. > for the subpackage. I think that would eliminate the build deps, but it > might make rpmdiff balk. I'm not sure. > > so three possibilities: > > 1) new module, new package, maitai process, etc > 2) sssd copies header in tree > 3) new subpackage > > I'm okay with 2 or 3, but you'll have to convince me harder for 1. > > Thoughts? Sorry when it was not clear but but I meant new sub-package. (In reply to Lukas Slebodnik from comment #5) > (In reply to Ray Strode [halfline] from comment #4) > > So the approach we ended up with was decided on in bug 1413900 comment 8 and > > bug 1413900 comment 9. > > > > As you point out the current approach doesn't add any runtime dependencies, > > and I don't think it adds any build loops, so it's not actually, practically > > speaking, a real problem is it? > > > > i don't really want to create new upstream module, and add a whole new > > package to rhel for this. That's a lot of overhead for a file with a few > > convenience macros in it. If the build dependencies are actually an issue, > > can sssd just copy the header file in tree ? > > > > Alternatively, I guess I could create a new subpackage, > > > > %package pam-extensions > > Summary: macros for developing pam extensions that GDM supports > > Group: Development/Libraries > > Requires: pam-devel > > > > And not have an explict > > > > Requires: %{name}%{?_isa} = %{epoch}:%{version}-%{release} > What would be purpose of this requires? > > Because it will if gdm-pam-extensions will depend on gdm than it would still > pull many x11/wayland related dependencies. > Because if gdm-pam-extensions depends on gdm then it will pull many x11/wayland related dependencies. And it would not solve anything. It woudl be the same situation as with gdm-devel. [root@ec786a0148ff /]# rpm -q gdm gdm-3.26.2.1-1.el7.x86_64 [root@ec786a0148ff /]# yum install gdm-devel Loaded plugins: ovl Resolving Dependencies --> Running transaction check ---> Package gdm-devel.x86_64 1:3.26.2.1-1.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: gdm-devel x86_64 1:3.26.2.1-1.el7 RHEL-7.5-x86_64-optional 28 k Transaction Summary ================================================================================ Install 1 Package (In reply to Lukas Slebodnik from comment #5) > > And not have an explict > > > > Requires: %{name}%{?_isa} = %{epoch}:%{version}-%{release} > What would be purpose of this requires? > > Because it will if gdm-pam-extensions will depend on gdm than it would still > pull many x11/wayland related dependencies. Exactly, we can't have the requires for that reason. Normally subpackages do have the requires to make sure the subpackage always gets upgraded in lockstep with the main package. > Sorry when it was not clear but but I meant new sub-package. okay sure. though i'm still curious why the extra build requirements are a problem. even if it were hundreds of build requirements, why would it matter (unless it creates build loops, i mean)? (In reply to Ray Strode [halfline] from comment #7) > (In reply to Lukas Slebodnik from comment #5) > > > > And not have an explict > > > > > > Requires: %{name}%{?_isa} = %{epoch}:%{version}-%{release} > > What would be purpose of this requires? > > > > Because it will if gdm-pam-extensions will depend on gdm than it would still > > pull many x11/wayland related dependencies. > Exactly, we can't have the requires for that reason. > > Normally subpackages do have the requires to make sure the subpackage always > gets upgraded in lockstep with the main package. > I am not rpm package expert but you might use following as well Conflicts: %{name}%{?_isa} < %{epoch}:%{version}-%{release} > > Sorry when it was not clear but but I meant new sub-package. > okay sure. though i'm still curious why the extra build requirements are a > problem. even if it were hundreds of build requirements, why would it > matter (unless it creates build loops, i mean)? A) It adds unnecessary 600+ MiB of build dependencies to sssd which causes little issues to our CI B) I do not use GNOME/GDM but I want to develop sssd with all available features C) Extra additional dependencies increase probability of problems in rawhide(but that's different BZ) And minimal devel package gdm-pam-devel(gdb-pam-extensions-devel or whatever name) is a win-win situation. Created attachment 1352086 [details]
proposed change
will push attachment 1352086 [details] if Brian is okay with this going in and gives a pm ack.
(In reply to Ray Strode [halfline] from comment #10) > Created attachment 1352086 [details] > proposed change Do you think it make sense to have suffix "-devel" in the name of new sub-package? Otherwise thank you very much. I really appreciate it. i don't think it really matters to be honest. we have lots of prior art where -devel isn't used (atleast xorg-x11-util-macros and kernel-headers off the top of my head). But I don't care either way, so I'll throw -devel in the name when i push. I can confirm that both the large list of dependencies is gone and pam-devel is now installed as a dependency, using the reproducer in the description. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0770 |