[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Yum-devel] system-config-packages and yum



On Wed, 2004-12-22 at 13:13 -0500, Paul Nasrat wrote:
> "The time has come", the monkey said
> "To talk of many things"
> "Of groups and comps and meta data"
> "Of packages and deps"
> "And why rawhide is boiling hot"
> "And whether yum has a gui"

nice. You missed your calling :)



> irc: 
> I'm usually on #rpm on freenode during the day - EST (UTC -0500), there
> is also the quiet #packaging channel we could abuse. I'm keen for this
> to be done in the open.

how about just #fedora-devel?


> Objectives:
> 
> 1) By end of January have the backend in place to use yum for s-c-
> packages in it's existing form (CD's, tree repos).

I talked about this, briefly, somewhere. About maybe adding an extra
file that just stores where the packages are for the cds. We'd need to
mark a repo as containing removeable media and take the appropriate
action on a failure.  But I think the structure should be there in the
repos.Repository.get() method to do that.

tree repos are just file:// repositories, I'd guess.  If you want it to
deal with just a bunch of rpms in a dir w/o the metadata that's a bit
more work but not impossible, just slower, I'd guess.



> 2) Look at extending the UI to handle network installs as well

I'll leave this to the UI people, but I reserve the right to bitch and
moan. :)


> 3) Future development discussion - dns-sd discovery and browsing of
> repos, etc.


I'm not familiar with dns-sd. what does it do/provide?


> It's possible that we'll end up with several uis for different types of
> task, lets concentrate on the current interface first and discuss future
> plans.
> 
> Organisation:
> 
> * Break down tasks and estimate
> * Short iterations - say a week
> * Release often, milestone releases scheduled
> * Unit tests and functional tests???
> 

fine by me.

I think most of the processes that need callbacks have them. I know of a
couple of places where adding in choices might be useful:

1. when you have multiple providers of the same package it would not be
difficult to add a select callback method to let the user tell us which
package to try. I hate the idea of doing this inside the text engine,
though I have considered it.

2. The downloadPkgs callback should have some total amounts added for
good total-process results.

Questions:
 How do we want to handle the configuration and repository mgmt for 
s-c-p? Just use the yum.conf and yum.repos.d and have an overlay for s-
c-p-specific configuration? Have a separate gui repository configuration
item to re-edit the .repo files?

-sv




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]