I believe the repoview pages in the Extras repository still cause some mirrors to choke on mirroring many hundreds to thousands of regenerated html files all few days:
extras-tree$ find . -name *.html|wc -l 61450
That's how many html pages are in Extras 5+6+devel presently!
The reason is that although repoview doesn't need to create all its web pages from scratch, it changes many of them too often due to the many package versions in them, which point to adjacent packages.
For example:
http://wftp.tu-chemnitz.de/pub/linux/fedora-core-extras/development/i386/rep...
The navigation bar at the left contains links to 20 packages, which come before and after "yap-devel" in the alphabetically sorted list of package names. It links to web page file names, which contain not only the package name, but also version and release. Changing any of the 20 packages changes the web pages for all its neighbours. Plus, the navigation bar lists not only the latest package release, but all releases (which is by design) found in the repo metadata, although it hides the version-release and causes confusion.
The more often packages in the neighbourhood of one package are changed, added or removed, the more web pages are updated due to the heavy use of package versions in them. Even deleting an old package release triggers such a rebuild of a chain of web pages.
IMO, we would do better in the short-term if we modified repoview to simplify the web page file names to just "%{name}.html". Then a package page would only be updated if the package changed actually or if the list of its 19 neighbours changed.
What is the estimated popularity of the repoview pages on our master download site and on the mirrors? Perhaps there are even plans on making a public interface to the package database obsolete repoview?
Comments?
That would actually be great, having %{name}.html, so you could link to it and not have it be supplanted by a new version. Maybe make this new functionality an option and have the old behaviour available. I don't care which is the default, but that's a great idea.
Disclaimer: I run a local private yum repo, and I have a 144k sync IDSL connection. Do the math. I would totally love this. :)))))
I believe the repoview pages in the Extras repository still cause some mirrors to choke on mirroring many hundreds to thousands of regenerated html files all few days:
extras-tree$ find . -name *.html|wc -l 61450
That's how many html pages are in Extras 5+6+devel presently!
The reason is that although repoview doesn't need to create all its web pages from scratch, it changes many of them too often due to the many package versions in them, which point to adjacent packages.
For example:
http://wftp.tu-chemnitz.de/pub/linux/fedora-core-extras/development/i386/rep...
The navigation bar at the left contains links to 20 packages, which come before and after "yap-devel" in the alphabetically sorted list of package names. It links to web page file names, which contain not only the package name, but also version and release. Changing any of the 20 packages changes the web pages for all its neighbours. Plus, the navigation bar lists not only the latest package release, but all releases (which is by design) found in the repo metadata, although it hides the version-release and causes confusion.
The more often packages in the neighbourhood of one package are changed, added or removed, the more web pages are updated due to the heavy use of package versions in them. Even deleting an old package release triggers such a rebuild of a chain of web pages.
IMO, we would do better in the short-term if we modified repoview to simplify the web page file names to just "%{name}.html". Then a package page would only be updated if the package changed actually or if the list of its 19 neighbours changed.
What is the estimated popularity of the repoview pages on our master download site and on the mirrors? Perhaps there are even plans on making a public interface to the package database obsolete repoview?
Comments?
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
After some modifications in repoview, here's what it could look like:
http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/
http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/repo...
*** Note that the download links to the packages don't work, as above URL is not a full repository.
Looks very good.
Slightly OT, is there a reason why this http://fedoraproject.org/extras/6/i386/repodata/ isn't thoroughly functional?
After some modifications in repoview, here's what it could look like:
http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/
http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/repo...
*** Note that the download links to the packages don't work, as above URL is not a full repository.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, 15 Mar 2007 09:50:50 -0500 (CDT), Jon Ciesla wrote:
Looks very good.
Slightly OT, is there a reason why this http://fedoraproject.org/extras/6/i386/repodata/ isn't thoroughly functional?
It's no repository anymore. Core and Extras are here:
http://redhat.download.fedoraproject.org/pub/fedora/linux/ -> http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repodata/
Excellent. I must have missed that. Thanks!
On Thu, 15 Mar 2007 09:50:50 -0500 (CDT), Jon Ciesla wrote:
Looks very good.
Slightly OT, is there a reason why this http://fedoraproject.org/extras/6/i386/repodata/ isn't thoroughly functional?
It's no repository anymore. Core and Extras are here:
http://redhat.download.fedoraproject.org/pub/fedora/linux/ -> http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repodata/
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thursday 15 March 2007 10:44:23 Michael Schwendt wrote:
After some modifications in repoview, here's what it could look like:
http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/
http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/rep oview/pbzip2.html
*** Note that the download links to the packages don't work, as above URL is not a full repository.
That looks pretty nice!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Maybe I've missed some mail with instructions, yum update its no working on Fedora 7 Rawhide. Is there any fix already for this - -- - - -- Nicolas A. Corrarello, RHCE c: +54 (911) 6398-5974 Fedora Ambassador Argentina e: ncorrare@fedoraproject.org GPG Key: DFC893EE h: http://www.fedoraproject.org/wiki/NicolasCorrarello GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B 7F8C E145 B2F9 DFC8 93EE Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007
On Thu, Mar 15, 2007 at 12:10:34PM -0300, Nicolas Antonio Corrarello wrote:
Maybe I've missed some mail with instructions, yum update its no working on Fedora 7 Rawhide. Is there any fix already for this
sudo yum clean metadata
try again.
On 15/03/07, Matthew Miller mattdm@mattdm.org wrote:
On Thu, Mar 15, 2007 at 12:10:34PM -0300, Nicolas Antonio Corrarello wrote:
Maybe I've missed some mail with instructions, yum update its no working on Fedora 7 Rawhide. Is there any fix already for this
sudo yum clean metadata
try again.
for the last couple of days rawhide hasn't been installable (pxeboot + ks from local mirror) 2 days ago yum crash, yesterday yum file conflicts, anyone know it it's stabilised at all today?
3 machines waiting to get testing on, if only I could install them (F7t2 from DVD has RAID1 issues for me)
On Thu, 2007-03-15 at 15:44 +0100, Michael Schwendt wrote:
After some modifications in repoview, here's what it could look like:
http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/
http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/repo...
*** Note that the download links to the packages don't work, as above URL is not a full repository.
Did you pass these modification upstream to the repoview maintainer?
I'm sure Icon would take a look at them.
-sv
On Fri, 16 Mar 2007 13:22:01 -0400, seth vidal wrote:
On Thu, 2007-03-15 at 15:44 +0100, Michael Schwendt wrote:
After some modifications in repoview, here's what it could look like:
http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/
http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/repo...
*** Note that the download links to the packages don't work, as above URL is not a full repository.
Did you pass these modification upstream to the repoview maintainer?
Yes, yesterday. Plus the original post went to him via Cc. ;)
I'm sure Icon would take a look at them.
My current proof-of-concept patch collection and changes summary is this: http://home.arcor.de/ms2002sep/tmp/repoview.patch
It reduces the size of repoview a tiny bit even. Making it a clean patch that adds the different package view as an option would require a lot of work, which I doubt would be worthwhile (considering the problems with the old structure and user interface).
Example for Fedora Extras 6 x86_64 + SRPMS here: http://buildsys.fedoraproject.org/plague-results/repoview-test/6/
One thing I'm still not sure about is what package details to display? Listing Vendor or Packager is not interesting when the values are constants (at least for Fedora) and when a changelog is printed.
I think Repoview is great for browsing the package groups, reading the package descriptions, learning about the package names, available versions, but it should not touch the area of old rpmfind, which listed low-level dependencies and other low-level details.
-
Andy Burns -
Jesse Keating -
Jon Ciesla -
Matthew Miller -
Michael Schwendt -
Nicolas A. Corrarello -
seth vidal