Spec URL: http://rmeggins.fedorapeople.org/fedora-ds.spec SRPM URL: http://rmeggins.fedorapeople.org/fedora-ds-1.1.1-1.src.rpm Description: Meta-package for Fedora Directory Server Suite Builds in mock, both f-8 i386 and x86_64. rpmlint says E: no-binary. This is a meta-package, the purpose of which is to simply provide Requires to pull in the other components (fedora-ds-base, fedora-ds-admin, console packages) of the Fedora Directory Server. It only contains the LICENSE file, in the %doc directory. The reason why it has an arch is so that it will pull in the correct architecture of the other packages such as fedora-ds-base which are architecture specific.
ill take this
looks good and is clean approved. builds in mock.
Updated due to rename of fedora-admin-console to fedora-ds-admin-console SRPM: http://rmeggins.fedorapeople.org/fedora-ds-1.1.1-2.src.rpm Spec: http://rmeggins.fedorapeople.org/fedora-ds.spec
New Package CVS Request ======================= Package Name: fedora-ds Short Description: Meta-package for Fedora Directory Server Suite Owners: rmeggins nkinder nhosoi Branches: F-8 InitialCC: Cvsextras Commits:
CVS Done
Um, this should be a noarch package: BuildArch: noarch
(In reply to comment #6) > Um, this should be a noarch package: > > BuildArch: noarch > Unfortunately, I don't think it can be a noarch package, because most of its dependencies are arch specific packages (fedora-ds-base, fedora-ds-admin). How would that work?
(In reply to comment #7) > Unfortunately, I don't think it can be a noarch package, because most of its > dependencies are arch specific packages (fedora-ds-base, fedora-ds-admin). How > would that work? We don't care about the architecture of dependencies.
(In reply to comment #8) > (In reply to comment #7) > > > Unfortunately, I don't think it can be a noarch package, because most of its > > dependencies are arch specific packages (fedora-ds-base, fedora-ds-admin). How > > would that work? > > We don't care about the architecture of dependencies. So if I do yum install fedora-ds on an x86_64 system, what happens? Does it pull in fedora-ds-base.x86_64 or fedora-ds-base.i386? If the latter, and I really want (and expect since I'm running on an x86_64 system) to get fedora-ds-base.x86_64 picked up as a dependency, how does that work?
Well, under the current setup, you would get both, with the x86_64 binaries taking precedence. Looks like current plan is to fix yum so that you would only get the preferred architecture. Why is fedora-ds-base multilib at the moment anyway? Is there any reason why you would want to run the 32-bit version on x86_64?
(In reply to comment #10) > Well, under the current setup, you would get both, with the x86_64 binaries > taking precedence. Looks like current plan is to fix yum so that you would only > get the preferred architecture. Ok. I guess at that point I can then make fedora-ds noarch? > Why is fedora-ds-base multilib at the moment anyway? Is there any reason why > you would want to run the 32-bit version on x86_64? Is it multilib? What makes it multilib? I don't think there is any reason to run the 32-bit version on x86_64.
comment #11) > (In reply to comment #10) > > Well, under the current setup, you would get both, with the x86_64 binaries > > taking precedence. Looks like current plan is to fix yum so that you would only > > get the preferred architecture. > > Ok. I guess at that point I can then make fedora-ds noarch? You could make it noarch now. > > Why is fedora-ds-base multilib at the moment anyway? Is there any reason why > > you would want to run the 32-bit version on x86_64? > > Is it multilib? What makes it multilib? I don't think there is any reason to > run the 32-bit version on x86_64. fedora-ds-base is multilib because it has a -devel sub-package. I believe you can black list it by sending a request to rel-eng.(In reply to
I'd like to see, and would be willing to maintain, EL-5 branches for fedora-ds and company in EPEL. Thoughts?