Bug 439210 - multiple problems with repository viewer
multiple problems with repository viewer
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: gnome-packagekit (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-27 11:29 EDT by Bill Nottingham
Modified: 2014-03-16 23:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-20 20:38:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
what PackageKit git looks like (26.94 KB, image/png)
2008-04-10 15:39 EDT, Richard Hughes
no flags Details

  None (edit)
Description Bill Nottingham 2008-03-27 11:29:34 EDT
Description of problem:

1) It allows users to enable debuginfo repos, which likely won't help them much
other than increasing all update times
2) It allows users to enable source repos, which doesn't really make sense at all
3) If you try to enable a repo, you get an error:

PackageKit daemon

Backends should send status <value> signals for repo-enable!

If you are:
* Calling out to external tools, the compiled backend should call
pk_backend_set_status() manually
* Using a scripted backend with dumb commands then this should be set at the
start of the runtime call
 - see helpers/yumBackend.py:self.status()

Version-Release number of selected component (if applicable):

gnome-packagekit-0.1.9
How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Bill Nottingham 2008-03-27 11:30:30 EDT
TBH, why is packagekit complaining to *me* that one of its backends is broken?
Comment 2 Richard Hughes 2008-03-27 13:27:06 EDT
We've already fixed the pk_backend_set_status thing in git (the messages are
just for developers, I'll turn them off for the release).

Do you think that we should hide the debuginfo and source repos completely or
make this configurable?
Comment 3 Bill Nottingham 2008-03-27 13:33:26 EDT
Not sure. TBH, ignoring them would be encoding some sort of Fedora-specific
repository layout information in the backend, which is kinda gross.

CC'ing other people for opinions.
Comment 4 Jesse Keating 2008-03-27 13:41:31 EDT
Would it help if there was some sort of descriptive comment about each repo? 
That way we can (hopefully) make it clear to the user what the repo is there for
and prevent them from shooting themselves in the foot?
Comment 5 Bill Nottingham 2008-03-27 14:04:39 EDT
Where would this come from? From the repo files themselves?

(Hey, I know. Let's move them to XML and intltool-ize them!)
Comment 6 Richard Hughes 2008-03-27 14:33:03 EDT
Well, we can do the filtering in a fedora specific way (using the abstract
FILTER_DEVELOPMENT) which is very easy to do.

What about just having a ticky box in pk-repo with "[ ] Show development
repositories" and classing -debuginfo and -source as DEVELOPMENT?

Richard
Comment 7 Bill Nottingham 2008-03-27 14:51:16 EDT
That will catch the people confusing 'rawhide' with 'Fedora development'.
Comment 8 Jesse Keating 2008-03-27 15:22:20 EDT
(In reply to comment #5)
> Where would this come from? From the repo files themselves?
> 
> (Hey, I know. Let's move them to XML and intltool-ize them!)

Well, we can try to put in more descriptive text in the name= line.  Save the
terseness for the [foo] part.  But yeah, English only for the lose.

Really, you can't rely on a name or a [foo] section to be sure that "these are
source packages" or "these are debug packages" because really, one can put any
URL there they want, and some have all of those types of packages mixed in together.
Comment 9 Richard Hughes 2008-03-28 08:56:58 EDT
Jesse, is there a way we could have a type= parameter?

Where type is:
* debuginfo
* source
* normal

That should be pretty easy to add, no?
Comment 10 Seth Vidal 2008-03-28 09:00:13 EDT
The only problem is that there's no logical limitation on what can be in a repo.

you can have source, binary, debug, etc rpms in one repo w/o any sort of logical
conflict.

so, we can put a type on it but it would just be an arbitrary label.
Comment 11 Richard Hughes 2008-03-28 09:19:47 EDT
Sure, I don't think type would have to be mutually exclusive. What about:

type=debuginfo

or

type=normal;debuginfo;source

Richard.
Comment 12 Jesse Keating 2008-03-28 09:50:02 EDT
The problem is that you're trying to define what will be in a remote repository,
that you have no control over.  I could /say/ that the development URL I'm
pointing at will be 'normal', but I can't prevent the person who runs that repo
from dropping debuginfo packages into it, or source packages.
Comment 13 Richard Hughes 2008-03-28 10:50:00 EDT
Well, the ultimate use case is a repo viewer with three entries:

[X] Fedora 9
[X] Livna 9
[ ] DAG 8.92
----------------------
[ ] Show detailed repository information

And if the last checkbox is enabled, then the -source, -debuginfo and such are
also shown.
Comment 14 Richard Hughes 2008-04-10 15:39:28 EDT
Created attachment 302057 [details]
what PackageKit git looks like

This is what the UI looks like when we filter out all the ~devel repos - this
isn't typical for rawhide users but cuts the list down to a few entries on F8
and F9. The average user doesn't care about -source repos much at all.

FWIW, I used this metric:

def _is_development_repo(self, repo):
  if repo.endswith('-debuginfo'):
    return True
  if repo.endswith('-testing'):
    return True
  if repo.endswith('-debug'):
    return True
  if repo.endswith('-development'):
    return True
  if repo.endswith('-source'):
    return True
  return False

When the repos can give us more information, then we can use that.
Comment 15 Richard Hughes 2008-04-20 20:38:47 EDT
I've merged this into 0.2.0 - which will be put into rawhide when it re-opens.
F9 still has the long list of repos as is based on the 0.1.x codebase.

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