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

Re: Yum-presto 0.3.7 and Extras



On Thu, 2007-04-05 at 18:10 +0200, Michael Schwendt wrote:
> On Thu, 05 Apr 2007 09:28:03 -0500, Rex Dieter wrote:
> 
> > Jonathan Dieter wrote:
> > 
> > > On Thu, 2007-04-05 at 07:04 -0500, Rex Dieter wrote:
> > >> Jonathan Dieter wrote:
> > 
> > >> What exactly needs to happen to make them presto-enabled?
> > 
> > > Two things.  I need to finish the createprestorepo tool so that it works
> > > pretty much identically to createrepo.
> > > 
> > > Then Fedora Infrastructure would need to use the createprestorepo script
> > > to build the deltarpms and the presto xml files for each repository.
> > 
> > When/if you have createprestorepo ready for wider consumption, let us know. 
> > I'd be willing to help drive the issue wrt FESCo, or whoever else needs
> > poking to make it happen.
> 
> Perhaps you can also talk a bit about the fate of repoview and whether
> the new updates system will keep it alive or whether there are
> short-term plans on replacing it with the PackageDB?
> 
> Meanwhile, the Extras push script runs my modified version to fight
> the thousands of superfluous html file updates, and it works nicely
> so far:
> 
> http://redhat.download.fedoraproject.org/pub/fedora/linux/extras/6/i386/repoview/ktorrent.html
> 
> If, however, there are plans on getting rid of it, it would have been
> nice if that had been told last month already when I started asking
> about repoview.
> 
Thanks for working on that problem!

Since I'm working on the PackageDB, I'll make this statement: There are
no short-term plans for replacing repoview with the PackageDB.

Long term, there are ideas floating around but they're still just
thoughts.  A lot of information regarding packages is going to be stored
in the combination of koji and the packagedb so it's very attractive to
have some user-focused web UI to display that information.  However, the
current interfaces and goals for both koji and the packagedb are to
enable packagers to maintain their packages more easily.  So the
end-user UI is a low priority in that respect.

Once we have time to look into an end-user UI, there will be a lot of
redundancy between repoview and the data we can pull out of koji.  So
we'll need to start asking ourselves what we like about repoview at that
point and whether we want the two to work together or if we only need
one of them.  (If repoview fits all of our needs, maybe there's no
reason for an end-user GUI for the PackageDB/Koji information.)

-Toshio

Attachment: signature.asc
Description: This is a digitally signed message part


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