Bug 435626

Of course, doing these things conflicts somewhat with the cross-packaging-system
nature of PackageKit. Enabling/disabling of repos is about the limit of what you
can do in a packaging-independent way, I'd say.

Not to be snarky, but I'm sure that will come as a great comfort to our users. 
And I hope that we don't ever develop any other new features that are only in
our system if PackageKit's stated goal is catering to the least common denominator.

There's no reason we can't do things like editing repos, we just need to figure
out a sane way to do it.  It would be trivial to do something crappy like put
the contents of the .repo file in a text box, or have a bunch of <name>: <value>
fields in a UI somewhere, but that would suck.  What are the real use cases? 
When I've actually needed to edit a .repo file for 'real world' use, it's been
to enable it or disable it, which we already do.

What does switching between baseurl and mirrorlist do for you?  Does it just
help if you can't find a good mirror?  If so, I'd argue that that's something
yum/PackageKit should do for you, not make you hand tweak.

The only other common option is the GPG checking, and honestly I'm quite happy
leaving changing that in 'open up a text editor' land.

For the adding repos case - is there ever a common case other than installing an
RPM that deploys the .repo file like livna (and adobe now, too - go them!) does,
or just downloading and installing a naked .repo file?

And we don't have to cater to the common denominator - PK already has a built-in
way to only present supported options to the user.  Notice the fedora version
doesn't have a 'rollback', but if you ran it on a conary system, you would get
that button.

Well, you can actually set stuff for the repos if you really wanted:

    <method name="RepoSetData">
      <annotation name="org.freedesktop.DBus.GLib.Async" value=""/>
      <arg type="s" name="tid" direction="in"/>
      <arg type="s" name="repo_id" direction="in"/>
      <arg type="s" name="parameter" direction="in"/>
      <arg type="s" name="value" direction="in"/>
    </method>

This allows you do do special things that are backend dependent, e.g. changing
the version number on the main foresight repo when you want to do a distro upgrade.

There's no reason the yum backend couldn't allow editing parameters, but Rob is
right in saying I'm not sure this is required.

By default, we should do the right thing, and users shouldn't have to understand
repos or all the other parameters. Most repos come with .rpm files that just work.

Richard.

There are plenty of cases where you have a site-local mirror and there is _no_
way to just divine that out of the ether.  It can even be not on the same local
net and yet still be "local", so even trying to make up some avahi excuse
doesn't cut it ;-)

And there are lots nad lots of sites that still have people add repo info by
hand.  And I don't see it going away anytime soon.

Sure, but the number of people running Fedora and have a local mirror must be a
tiny preportion of the total installed base. Plus, the sort of people who run
schools and large deployments with local mirrors are quite capable of editing
the repo file by hand or installing a new one at kickstart time.

Adding and removing repos is a more concrete use case, although if we add this
we have to do it in an abstract way. Could you point me a some howtos and faq of
real world users using pirut to install a repo? I would be interested to see how
they are taking them through the steps and if maybe we can improve the user
interaction by being cleverer.

I'd like to add my use case to the mix.

I maintain the Dell yum repositories:
  http://linux.dell.com/repo/software
  http://linux.dell.com/repo/hardware
  http://linux.dell.com/repo/firmware

Currently, I maintain a somewhat-complicated bash script that I ask customers to
run (bootstrap.cgi) to set up their system. The way I have to set up the system
is different for RHEL4 (up2date), CENTOS4 (yum), RHEL/CENTOS 5 (yum) and SLES10
(rug).

The repo setup involves installing an RPM with yum .repo files, but there is a
lot of added complexity involving both up2date and rug.

It would be nice if there were a simple way to tell my customers: run XYZ local
command to set up your system to point at our repos.

*** Bug 441386 has been marked as a duplicate of this bug. ***

Michael, why don't you just give a single .rpm (with a contained .repo file and
gpg keys) for each distro? The user installs that, and it's all setup and
working, with only one authentication prompt (for the unsigned local file install).

Is there any convincing use case for letting end users edit repo files?

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I'm closing this bug as very few users seems to be bothered by this missing
functionality. Sorry.