Red Hat Bugzilla – Bug 253184
Merge fedora-package-config-{apt,smart} into fedora-release?
Last modified: 2015-02-18 06:56:32 EST
Currently smart and apt have their own packages that correspond to fedora-release's yum config (they are derived from fedora-release's config of course). Whenever fedora-release changes like at the beginning of a devel cycle, or during test cuts or especially at the end of a devel cycle (e.g. at release time) the other two packages lag behind often seriously breaking stuff (like still pointing to rawhide when a release is frozen, this happened at the F7 release where the layout was not known beforehand - for F8 and later this is less a problem unless the layout has to change again). It would therefore make sense to maintain them at a single place, e.g to have fedora-release swallow in fedora-package-config-{apt,smart}. I would be willing to do the merging and later help maintain them within fedora-release. (a small headache would be the BuildArch: noarch, as smart has no variables for archs)
Hrm. While I immediately want to say no, I'm not going to without some thought (: The noarch to arch thing isn't a small headache, it's a pretty big issue. I'd feel /much/ better about this if smart would take a teensy amount of time and grow an arch variable. <crazy_thought> how different are the configs for yum vs apt vs smart, and if yum were willing to take on some config items that were otherwise unused by yum, could these tools not use the existing yum configs directly and not need to re-invent the config file wheel? </crazy_thought>
Well, many users have expressed the demand to unify the config spaces somehow for all tools, and I think this will eventually happen, but not in the near future. It doesn't look like rocket science, but it does take some work to make it happen. I'll look how difficult it is to make smart at least noarch-config. If that were the case would you go for a merger? :) (and when would the freeze date for that be? I'll be doing a cross-Europe relocation soon, so I can't promise any sensible ETA for massaging smart into a noarch state)
Well, we're past the feature freeze and thus a bit too late for F8. Try again for F9 maybe? I'm still not exactly convinced I want to do this, but...
I'm closing deferred until smart has noarch configs.
(In reply to comment #4) > I'm closing deferred until smart has noarch configs. There is no ETA/entry on the developers' TODO list for something like this, and DEFERRED means "The problem described is a bug which will be fixed when the next major release is released, but which is not planned to be released in the release against which the bug was filed. A explanation of why this resolution has been chosen should be supplied.." E.g. it implies it has been fixed and people would assume it would automatically make it into the next rebuild which is not the case. With F8 it happened again that the configs desynced. The only way to ensure synced depsolver settings in the transitions from rawhide -> test -> rawhide -> release -> etc. is to manage them all at one place (and by a release-eng team member who knows when and where branches are made, the configs need cahngeing the paths have been altered etc.). Please pick this up for F9. Thanks!
I'm not going to include them until they can be arch inspecific. We'll likely break them anyway if they aren't using mirror manager when we use redirects late in the stage. If Deferred doesn't work, I'll just go WONTFIX.
Would it be possible to re-open this ticket as Smart now has the required functionality? The functionality is the yumsync plugin which imports channels from those defined for yum. yumsync also supports the $releasever and $basearch variables so is release/arch inspecific. The yumsync plugin can be enabled by adding the following to the distro.py file in the code section starting 'if not sysconf.getReadOnly():' if not sysconf.has("sync-yum-repos"): sysconf.set("sync-yum-repos", True, weak=True) As a suggestion this can be implemented in the following ways: 1) adjust the distro.py file as above. Remove the dependancy of smart on the fedora-smart-config package (as distro.py is distributed in the Smart main package) and remove fedora-config-smart from the repository. 2) remove the files installed by fedora-config-smart in /etc/smart/repos.d (non-dynamic repository/channel configuration). Move the distro.py file (which contains distribution specific configuration for Smart) from the main Smart package to the fedora-config-smart package after applying the above changes. Implementing this change will fix the problem with the Smart config always being broken in alpha/beta/release candidate/new releases.
Sorry, where I mention 'fedora-config-smart' above I should have said 'fedora-package-config-smart'
Feel free to re-open and post patches :)
I seem to be unable to re-open this ticket. Any hints on what i'm doing wrong?
No idea, but I re-opened it for you.
Created attachment 457627 [details] Smart spec file which obsoletes fedora-package-config-smart and an adjusted distro.py The two files in this zip replace the corresponding files in the smart source package.
Created attachment 457628 [details] Option 2: These files remove the distro.py from the smart package and move it to the fedora-package-config-smart package They also remove the smart channel configuration files from the fedora-package-config-smart package as they are obsoleted. The distro.py file is updated to enable the yumsync plugin.
Apologies in advance as it's been some years since I have looked at any rpm packages. I haven't been able to test the spec files either as I haven't got access to my Fedora machine right now.
Moving this to smart for now.
Thanks for the note on the new functionality, getting rid of the extra config packages would be great. I'll do some testing and if it's ready for production, let's get rid of this package (or merge into fedora-release). I remember that there was even a mirrorlist plugin in the works, maybe that's ready for prime time, too. BTW there happen to be new smart packages as of yesterday for unrelated fixes and updates in testing.
Yes there have been some good changes coming through. The yumsync plugin actually uses mirrorlists so you get it for free by enabling it. I have used it a fair ammount and it works great (generally hits a mirror if it can). I was actually involved in developing the mirrorlist plugin but that was a long time ago. The only downside with mirror handling is that it doesn't populate the native mirror list in smart. In my view the mirrorlist plugin should populate the mirrors list in Smart. Thus a user can view the mirrors/remove broken mirrors etc and Smart itself can re-prioritise the mirrors based on reachability. Unfortunately this didn't convince the devs and they went for the alternative which was to import and use the mirrors but not use the native Smart mirror functionality. Still the important thing is that $basearch, $releasever AND mirrorlists are now supported. It occurred to me as I was falling asleep last night (omg dreaming about spec files) that I did not adjust the files section of the spec file so there is probably a problem there that needs fixing. I'll see if I can test the smart package in testing soon. It looked like these are the fixes for the recent glib breakage with the dialogs, right? A couple of things off topic. I would be interested in using qt4 interface if possible. If the gtk and qt interfaces can be split into separate sub-packages then they could be conditionally installed depending on which desktop is installed when smart is installed (both if a gtk desktop and kde are installed). Related to installing smart I have been poking Anders to make the install more configurable. This came up on the smart mailing list recently when someone complained about having to install stuff that was not related to thier own package manager. Thus it should be possible (hopefully in smart 1.4) to drop all the non-fedora/non-yum/non-rpm stuff from the smart package. Not seeing all this un-related cruft (apt/arch repos etc) makes the interface much cleaner, less confusing and more useable (although this is of less importance if the yumsync plugin is enabled). If you are (still) in the mood for possible improvements these may also be of interest: The Smart manual (a docs package? I don't have much info on this) https://code.launchpad.net/~afb/smart/groups (views based on comps.xml, very useful) https://code.launchpad.net/~afb/smart/sqlite (the newer yum database format) The last two have probably stagnated a bit but might be very nice to have.
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
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.