Repository feature proposal

Daniel Veillard veillard at redhat.com
Sun Oct 19 19:29:35 UTC 2003


On Sun, Oct 19, 2003 at 02:45:15PM -0400, seth vidal wrote:
> > Similar problems occur with other formats. Try a multibyte character one
> > byte of which is '"' or '\n' in .ini format.
> > 
> > XML also makes the format extensible and means you already have tools to
> > autogenerate it, to turn it into up2date lines, yum lines, html, or edit it.
> > 
> 
> This was something I was talking about with some other folks on irc - if
> there was an xml representation of a 'definition' of a
> repository/channel - then you could write converters/renderers for all
> the other layouts.
> 
> going from xml to any other format is pretty easy.

  Right. XML doesn't have to be the only representation for those data,
but it's a good one for interchange and automated processing. I'm not
suggesting to expose it to users, there should be more appropriate ways
to show them or update them. As well as HTML became an ubiquitous format
for informations targetting humans, 99% of the time we never look at the
HTML format directly but though tools, the ability of editing XML directly
is not the best reason to use it, it's overall reliability, ubiquity,
precise parsing semantic, I18N and extensibility which are the long term
reasons to choose it when it makes sense. I didn't expected to raise such
a thread just about this.

  Speaking with my Red Hat hat off...
  Having metadata about mirrors would be generally useful, not only for
yum but in a more general sense for mirroring. Integrating mirror
informations within those metadata might be an interesting way to
propagate this information up to the client and split the load among
servers. This can connect to a large amount of other information 
pools like centralized list of mirrors, relationship with extra
add-on repositories, etc... As the person who manage rpmfind.net and who
somewhat failed to build a working distributed infrastructure I'm
really interested in the technical solutions we may build to propagate
the repositories and mirrors informations down to the client and have 
a good working distributed framework to automatically update systems.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/





More information about the fedora-devel-list mailing list