Bug 834603
|
Description
Giuseppe Ragusa
2012-06-22 14:41:07 UTC
Created attachment 593770 [details]
Proposed spec file
Created attachment 593771 [details]
Proposed DC SysVinit control script
Modified spec file attachment into a "diff -Naur" patch versus latest package release (58beta2) which still exhibits the aforementioned problems Created attachment 594194 [details]
Spec patch versus latest (58beta2) package release
I see your reasons and fixing things like that is OK. However, please think about following scenario because this is what will happen in some mid- to long- term perspective. In future we'll want to get back to a single samba package instead of samba and samba4 split. Samba 4 contains the same daemons and public libraries as in samba (3.x) packages so functionality-wise this will work fine. However, when doing AD/Heimdal and MIT Krb5 build, all other subpackages will be affected as well, changing their libraries' ABI. In particular, libsmbclient will be linked with internal Heimdal version which would then cause issues for packages linked against libsmbclient. Your rebuilt samba-4.x package would not be able to be installed as replacement of samba-4.x package provided by default (with MIT Krb5 build). We need to solve this issue somehow before giving a promise on dual-build. How about modifying the spec so that when enabling dc we make a second configure without-dc and with-mit-krb5, then build (both in a separate tree) and finally we install hand-picking only the client side bits (overwriting the Heimdal-based ones)? Created attachment 595555 [details]
Spec patch versus latest (59beta2) package release
I don't think it will help as dependencies for each version spread over the whole code base. You are welcome to experiment and demonstrate that this approach would work. What is needed is a package, where dc version is built and installed into its own sandbox, lets say, %_libdir/sambadc where the whole install tree would be there. One particular issue with this approach is that you'll need to force generated ABI dependencies within dc subpackage dropped or otherwise there will mess of multiple libfoobars provided. Also path searching for python code would need to be modified to not clash with mitkrb5 version. Created attachment 602237 [details]
Spec patch versus latest (133.beta5) package release
I tried to adapt my private old "isolated -tree" samba4 spec (I was installing into /opt around alpha17), but satisfying all the requirements which were rightly mentioned goes beyond my available time at the moment. Reading the latest discussions on samba-technical and the rationale around latest Fedora 18 samba4 announcements, I propose to simply modify the spec along the lines of my latest submitted patch: *) ensure package is actually able to rebuild on stock RHEL6 (I reverted the tdb/talloc/tevent building mods as RHEL has too old versions for the time being; furthermore iniparser is not available and neither is python-tevent) *) make sure that paths and support files for latest Fedora features/conventions are correctly managed under RHEL6/older Fedora (usrmove, volatile /run in place of /var/run, tmpfiles.d) *) leave DC support off by default, but make sure that someone who manually modifies the spec to build it has all the remaining parts already in place (for RHEL6 too): he must "manually" ensure not to mix the resulting packages with standard but ABI-conflicting packages; if we can add Conflicts lines to the DC subpackages it would be nice but I lack the knowledge to that myself, to the point that I don't even know if it is feasible. Created attachment 602245 [details]
Spec patch versus latest (133.beta5) package release
Corrected "with_dc" option erroneously left to enabled by default.
I might add some things from the patch in future but can't do it right now. The spec file correctly builds for RHEL 6.4, RHEL 7.0 and Fedora. Applying your patch would break RHEL 6.4. I infer from comment #12 that RHEL 6.4 will have the tdb/talloc/tevent packages rebased, bringing in also the required python-tevent (and iniparser too). I tested only on RHEL (actually CentOS) 6.3 fully up-to-date, but I would really like to reduce my patch to the bare minimum that could eventually be accepted (maybe only in the future) so I will assume that those dependencies are met and I will rework the patch. Could someone please confirm/reject the following assumptions (sorry for insisting :> ): 1) the move to a "volatile" /var/run under /run (and the associated tmpfiles.d mechanism) happened in Fedora 15 and won't appear in RHEL until 7.0 (henceforth the need to conditionally modify the various references to /var/run and /run and the including of /etc/tmpfiles.d/* support files) 2) SysVinit control scripts usually have 755 permissions, sometimes 555, but never 644 except for "include-style" support files (henceforth the need to modify the install permissions) The remaining part of my patch (barring some overzealous corrections on my part that I will promptly remove) deals with AD DC support and its SysVinit/Systemd resources and comes into play only manually enabling the %with_dc global (but if there's something incorrect or dubious in this part I'd like to know it). Many thanks for your attention. Created attachment 609612 [details]
Spec patch versus latest (137.beta7) package release
Created attachment 609614 [details]
Spec patch versus latest (137.beta7) package release
Corrected copy'n paste typo.
Created attachment 611674 [details]
Spec patch versus latest (138.beta8) package release
Updated patch to latest Rawhide package, removed some erroneous corrections and fixed changelog entry.
Created attachment 613981 [details]
Spec patch versus latest (139.rc1) package release
Updated to latest spec and modified dc post/postun/preun scriptlets to use new systemd-rpm macros for F18 and RHEL7.
Created attachment 616403 [details]
Spec patch versus latest (140.rc1) package release
Updated to latest spec from Rawhide.
Looking at latest Rawhide sources I see that samba4 package has been renamed as samba and the spec "rebased" on the latest samba 3.6.x version without any RHEL6 compatibility logic (I suppose that this is the way forward for Fedora 19 and RHEL 8).
If the previous package release (140) is the supposed way forward for RHEL 6/7 then I'd like to change product to RHEL on this bug and maybe incorporate some tweakings from the latest Rawhide (like enabling cluster support and maybe lib{smb,wb}client) but still using that (140) spec as reference.
Can anyone from RHEL team comment on this?
Many thanks.
The current samba package in rawhide and f18 are only supporting f18 and newer versions. There will be a samba4 package version 4.0.0rc1 in rhel6. So the spec file for this packages has been fixed for rhel6 especially. This version is targeted for RHEL7 not RHEL8 and it is an official converged version upstream. If you need some special backporting to 3.6 in RHEL6.x please open separate RHEL RFEs and we will se what we can do. A lot has changed in Samba between 3.6.x and 4.0 so most likely some of the features would be very hard to backport. I understand comment #20 as a (partial) confirmation of my comment #19 and comment #21 as a further clarification adding that RHEL 7 too will use the converged samba package based on Samba4 Regarding comment #21 I must clarify that I do not have here any interest in the line of code of Samba 3.6.x (nor backports of any sort), but: *) I (as a side note) suppose that RHEL6 too (as RHEL5) will switch to Samba 3.6.x as the fully supported stable samba version (actually the samba3x optional package, speaking of RHEL5) *) I suppose that the samba4 package will remain "separate as this" for the life of RHEL6 (much like tha samba3x in RHEL5) *) the officially provided samba4 packages in RHEL6 will have the sole stated purpose of supporting OpenChange and maybe FreeIPA *) the samba4 package in RHEL6 will soon (maybe in RHEL6.4) be rebased to the (at least initially) RC1 Samba4 release (with no DC functionality compiled in) Given the above points (which you are obviously free to confute), I suppose that the latest samba package in Rawhide sources no longer reflects the samba4 package that will be in RHEL6 (but only the Fedora18/RHEL7 samba one), so that if I want to maintain a patch / discuss changes (with the hope of seeing them [albeit partially] integrated in the future) I do not have a reference src.rpm any more (i.e. where is the RHEL6 samba4 package referred to in comment #20 ?) Do I need to wait for a future RHEL6.x beta or can we continue discussing it here referencing the last relevant samba4 spec (the 140.rc1 one)? If so, doesn't it make more sense if we change product to RHEL on this bug? (In reply to comment #22) > I understand comment #20 as a (partial) confirmation of my comment #19 and > comment #21 as a further clarification adding that RHEL 7 too will use the > converged samba package based on Samba4 > > Regarding comment #21 I must clarify that I do not have here any interest in > the line of code of Samba 3.6.x (nor backports of any sort), but: > > *) I (as a side note) suppose that RHEL6 too (as RHEL5) will switch to Samba > 3.6.x as the fully supported stable samba version (actually the samba3x > optional package, speaking of RHEL5) > > *) I suppose that the samba4 package will remain "separate as this" for the > life of RHEL6 (much like tha samba3x in RHEL5) > > *) the officially provided samba4 packages in RHEL6 will have the sole > stated purpose of supporting OpenChange and maybe FreeIPA > > *) the samba4 package in RHEL6 will soon (maybe in RHEL6.4) be rebased to > the (at least initially) RC1 Samba4 release (with no DC functionality > compiled in) > Those are correct statements. > Given the above points (which you are obviously free to confute), I suppose > that the latest samba package in Rawhide sources no longer reflects the > samba4 package that will be in RHEL6 (but only the Fedora18/RHEL7 samba > one), so that if I want to maintain a patch / discuss changes (with the hope > of seeing them [albeit partially] integrated in the future) I do not have a > reference src.rpm any more (i.e. where is the RHEL6 samba4 package referred > to in comment #20 ?) The new samba in rawhide has everything other than DC. AFAIU for what you are trying to accomplish you need to port your features to the package available in rawhide. Then if you want to see the same issue addressed for RHEL 6 you can open a separate BZ and attach the current patch you have there. A bit of double maintenance but unfortunately there is no other way. (In reply to comment #23) ... > The new samba in rawhide has everything other than DC. AFAIU for what you > are trying to accomplish you need to port your features to the package > available in rawhide. I'm including a revised patch for DC functionalities only, referring to latest Rawhide sources. > Then if you want to see the same issue addressed for RHEL 6 you can open a > separate BZ and attach the current patch you have there. > A bit of double maintenance but unfortunately there is no other way. I've opened bug 862194 to keep working on RHEL6 version, changing subject here accordingly (the RHEL6 support issues are not pertinent here anymore). Created attachment 620199 [details]
Spec patch versus latest (150.rc1) package release
Comment on attachment 593771 [details]
Proposed DC SysVinit control script
No more relevant (unused in Fedora).
Created attachment 622289 [details]
Spec patch versus latest (151.rc2) package release
Removed version/changelog parts to keep the patch more compatible to future package releases.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Created attachment 945120 [details]
Patch against latest samba.spec
Changing the package name to append a "4" when building with DC support permits differentiate samba AD/DC enabled/disabled packages:
samba-dc: DC is disabled
samba4-dc: DC is enabled
On this way, fedora can provide the two build variants.
Created attachment 945127 [details]
Corrected version of previous patch
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |