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.