Re: fc4, yum and s-c-p

I hope I'm not offtopics here, but would it be possible to merge yum 
with bittorrents to increase download speeds? Or is that unneccessary?

Just my $0.02

seth vidal wrote:

>Hi Folks,
> Some rough ideas for fc4 system-config-packages and yum.
>
>1. interface layout: http://primates.ximian.com/~joe/Screenshot.png
> I actually like some bits of that picture of red carpet. Do we have any
>mock ups of what multiple lists of packages would/will look like for pkg
>mgmt through a gui interface? Is there someone at who I might be
>able to harass for this stuff?
>
>2. other callbacks and callback refinement needed. Right now I've
>plugged callbacks into wherever I could think of that feedback was
>needed. I'm still using the log functions for debug feedback in the yum-
>module, but I've isolated all non-lib feedback into cli.py, output.py
>and the rpm callback in yum-cli. If either of you would like to look
>through the yum module (subdir yum in the tarball) and look for places
>that need more feedback, I'd appreciate it. All of the functions raise
>errors, nothing sys.exit()s anymore.
>
>3. I need to make the exceptions easier to deal with. Either error numbers or 
>separate sub-exceptions for each type of error.
>
>4. transactioninfo.py - in order to get back more detailed information
>of what has happened in the the transaction I need to finish off and use
>transactioninfo.py. In terms of the code all it ultimately means is
>easier searching of what we've added to the transaction set.
>
>5. repository editing/handling. One of the problems with the current
>repository code is handling editing of the files from the gui. The way I
>see it we can either:
>  a. write out configparser files to replace the ones on system
>  b. setup a new xml standard for repository declaration (let's call
>it /etc/repos.d/ and work entirely from that. The current config code
>should be able to cope with this w/o much trouble - just a new method to
>read the data in.
>  c. do something else altogether different.
>
>6. rhn/xml-rpc - I don't know this from adam's housecat - so I'm not
>sure what we want to do here. I'm not sure how it works but if it works
>as I think it does I believe we can modify the current yum depsolver to
>talk to it - if we just want to use it to get packages then that will be
>utterly trivial - but the metadata will have to come from somewhere.
>Setting up a list handler to make packages available via rhn visible as
>an YumAvailablePackage Objects shouldn't be too hard. I just need the
>metadata and a definition on how to get to it.
>
>
>7. drag-n-drop/doubleclick-install - the yum localinstall stuff was
>implemented with this in mind. It's all handled through the
>YumLocalPackage class in yum/packages.py. This should be completely
>simple to do double-click/drag-n-drop support.
>
>8. gpgkey handling. utterly blank here. :)
>
>9. rhnapplet/yumapplet/packageupdate applet - I have some ideas here
>but:
>  a. I'm not convinced they're not crack
>  b. I'm not convinced they won't make for an incredibly heavy-weight
>applet
>  c. I'm worried about them being performant
>
>okay.
>
>I think those are all my rough thoughts on the subject.
>
>I'll be working on the rest of the infrastructure bits we'll need, but
>I'd like to get a prototype glued to a prelim gui VERY soon. My pygnome/
>pygtk programming is non-existent other than the simplest of the demos.
>I would like to learn it and I'm willing to spend some time on it - but
>I know my interface design will suuuuuuuuuuuuuuuuck so I'm hoping some
>interface people have some ideas.
>
>
>
>Thanks,
>-sv
>
>
>
>
>  
>

-- 
Fedora-config-list mailing list
[email protected]
http://www.redhat.com/mailman/listinfo/fedora-config-list