Bug 238561
Summary: | apt for el requires fedora-release | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Andreas Müller <redhat> |
Component: | apt | Assignee: | Axel Thimm <axel.thimm> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | el5 | CC: | pmatilai |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-05-07 13:17:02 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Andreas Müller
2007-05-01 13:58:28 UTC
The dependency on fedora-release is just a leftover from times before the configuration was split to fedora-package-config-apt. Apt itself doesn't need fedora-release in any way, apt::distroverpkg=fedora-release in fedora-package-config-apt creates the dependency. The right thing to do is to move the dependency from apt package to fedora-package-config-apt. I'm not sure whether apt will be able to pull from RHN RHEL channels, so probably putting apt on epel was an unwise decision to start with :/ (In reply to comment #2) > I'm not sure whether apt will be able to pull from RHN RHEL channels, so > probably putting apt on epel was an unwise decision to start with :/ At least you can use apt with the repodata from EPEL and CentOS (yes, that's why you guys called it EPEL and not EPRHEL...) Apt wont be able to pull from RHN (of course it would be possible to teach it how to do that but I'm not interested) but like Andreas said, there's CentOS as well. (In reply to comment #0) > fedora-release >= 4 is needed by apt-0.5.15lorg3.2-9.el5.i386 That's not the problem. > apt-config is needed by apt-0.5.15lorg3.2-9.el5.i386 This is. Shipping apt with an empty config, or a config that will not be able to resolve dependencies makes little sense. Adding CentOS URLs for the base also sounds wierd and would require a sign-off by higher instances. Regardless of the CentOS/RHEL politics, the right thing to do is to move the fedora-release dependency out of the main apt package (it's just plain wrong there) into the package providing apt-config for both Fedora and EPEL. (In reply to comment #6) > Regardless of the CentOS/RHEL politics, the right thing to do is to move the > fedora-release dependency out of the main apt package (it's just plain wrong > there) Yes, I agree. FC4 is history anyway. But > into the package providing apt-config for both Fedora and EPEL. That package does not/cannot exist in EPEL unless it starts including CentOS/SL/<your favourite rebuild> URLs. BTW the same is true about smart. (In reply to comment #7) > (In reply to comment #6) > > into the package providing apt-config for both Fedora and EPEL. > > That package does not/cannot exist in EPEL unless it starts including > CentOS/SL/<your favourite rebuild> URLs. I'm perfectly well with an apt package without dependency on config files, as I have my own private mirror and therefore custom repo configs, but that's probably just me and I could roll my own package. However, I've never requested that you add CentOS/whatever URLs to the files, and I think that this approach is the worst one can do from Red Hat's point of view. Getting unmet dependencies is very ugly when one uses a depsolver, but Axel's own apt-config, provided by atrpms-package-config, isn't useful on RHEL as well, as it only contains the atrpms repos. So what would be the next step to resolve this bug? Fix the dependencies or completely remove apt from EPEL? (In reply to comment #8) > Getting unmet dependencies is very ugly when one uses a depsolver, but Axel's > own apt-config, provided by atrpms-package-config, isn't useful on RHEL as well, > as it only contains the atrpms repos. You're confusing things, this has nothing to do with ATrpms (which provides SL repos BTW and not only atrpms repos - only that SL5 is not yet officially out, check the RHEL4 package if you're really interested in the underlying mechanics). apt-config is provided by fedora-package-config-apt. That's the package that provides yum's counterpart in apt speech. But as noted before the RHEL base packages cannot be mapped, or they would need to be mapped onto CentOS/SL. I'm not advertising to do the latter, just showing what would be needed. I probably jumped the gun when importing apt/smart into epel. You can take the specfile and modify it to use the private repos, of course. (In reply to comment #9) > (In reply to comment #8) > > Getting unmet dependencies is very ugly when one uses a depsolver, but Axel's > > own apt-config, provided by atrpms-package-config, isn't useful on RHEL as well, > > as it only contains the atrpms repos. > > You're confusing things, this has nothing to do with ATrpms (which provides SL > repos BTW and not only atrpms repos - only that SL5 is not yet officially out, > check the RHEL4 package if you're really interested in the underlying mechanics). OK, I haven't noticed the medley-package-config rpm with the URLs for SL. Nevertheless, on http://www.atrpms.net/ your packages are announced as being built for (and I think also on) RHEL. But that is not my main concern and somewhat OT here. > apt-config is provided by fedora-package-config-apt. That's the package that > provides yum's counterpart in apt speech. But as noted before the RHEL base > packages cannot be mapped, or they would need to be mapped onto CentOS/SL. I'm > not advertising to do the latter, just showing what would be needed. Agreed. > I probably jumped the gun when importing apt/smart into epel. So again my question: Do you want to remove apt and smart from epel? This should be possible at present, as EPEL hasn't been announced yet (or did I miss something?). (In reply to comment #10) > > I probably jumped the gun when importing apt/smart into epel. > > So again my question: Do you want to remove apt and smart from epel? This should > be possible at present, as EPEL hasn't been announced yet (or did I miss > something?). Yes, it would be possible. I'm still thinking what would be best. Since apt/smart only makes sense w/o RHEL (unless you create your private repo like yourself), I should probably ask at CentOS/SL camps what they think. The worst case scenario would be epel shipping a configless apt/smart and this replacing the clones' apt/smart _and_ config. People would get quite upset. (In reply to comment #11) > I'm still thinking what would be best. Since apt/smart only makes sense w/o RHEL > (unless you create your private repo like yourself), I should probably ask at > CentOS/SL camps what they think. > > The worst case scenario would be epel shipping a configless apt/smart and this > replacing the clones' apt/smart _and_ config. People would get quite upset. I can't speak about SL, but on CentOS there is neither apt nor smart. They ship yum (also for CentOS 4), so this is the only config one has to care about. > > > I probably jumped the gun when importing apt/smart into epel.
> >
> > So again my question: Do you want to remove apt and smart from epel? This
> > should be possible at present, as EPEL hasn't been announced yet (or did I
> > miss something?).
>
> Yes, it would be possible.
OK, the apt/smart related packages are gone from the repo since a couple of days.
Since I also quit epel today, if apt or smart ever get rhn support someone else
will have to pick it up for epel.
|