Bug 253184 - Merge fedora-package-config-{apt,smart} into fedora-release?
Summary: Merge fedora-package-config-{apt,smart} into fedora-release?
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-package-config-smart
Version: 19
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Axel Thimm
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F9Target
TreeView+ depends on / blocked
Reported: 2007-08-17 11:07 UTC by Axel Thimm
Modified: 2015-02-18 11:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-18 11:56:32 UTC

Attachments (Terms of Use)
Smart spec file which obsoletes fedora-package-config-smart and an adjusted distro.py (4.64 KB, application/x-zip-compressed)
2010-11-04 00:41 UTC, Rehan Khan
no flags Details
Option 2: These files remove the distro.py from the smart package and move it to the fedora-package-config-smart package (6.64 KB, application/x-zip-compressed)
2010-11-04 00:52 UTC, Rehan Khan
no flags Details

Description Axel Thimm 2007-08-17 11:07:25 UTC
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

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

Comment 1 Jesse Keating 2007-08-17 11:50:02 UTC
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.

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?

Comment 2 Axel Thimm 2007-08-17 16:54:15 UTC
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)

Comment 3 Jesse Keating 2007-09-18 20:01:32 UTC
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...

Comment 4 Jesse Keating 2007-11-15 16:58:53 UTC
I'm closing deferred until smart has noarch configs.

Comment 5 Axel Thimm 2007-11-29 17:53:25 UTC
(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

  "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!

Comment 6 Jesse Keating 2007-11-29 18:01:25 UTC
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.

Comment 7 Rehan Khan 2010-11-03 13:14:23 UTC
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.

Comment 8 Rehan Khan 2010-11-03 13:31:07 UTC
Sorry, where I mention 'fedora-config-smart' above I should have said 'fedora-package-config-smart'

Comment 9 Jesse Keating 2010-11-03 17:16:50 UTC
Feel free to re-open and post patches :)

Comment 10 Rehan Khan 2010-11-03 19:20:11 UTC
I seem to be unable to re-open this ticket. Any hints on what i'm doing wrong?

Comment 11 Jesse Keating 2010-11-03 20:55:08 UTC
No idea, but I re-opened it for you.

Comment 12 Rehan Khan 2010-11-04 00:41:29 UTC
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.

Comment 13 Rehan Khan 2010-11-04 00:52:38 UTC
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.

Comment 14 Rehan Khan 2010-11-04 00:56:22 UTC
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.

Comment 15 Jesse Keating 2010-11-04 17:59:12 UTC
Moving this to smart for now.

Comment 16 Axel Thimm 2010-11-04 19:47:24 UTC
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.

Comment 17 Rehan Khan 2010-11-04 23:55:33 UTC
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.

Comment 18 Fedora End Of Life 2013-04-03 19:59:11 UTC
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:

Comment 19 Fedora End Of Life 2015-01-09 21:35:56 UTC
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.

Comment 20 Fedora End Of Life 2015-02-18 11:56:32 UTC
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

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.