On Tue, Jul 11, 2017 at 09:50:31AM +0200, Vít Ondruch wrote: > Dne 10.7.2017 v 19:31 Pierre-Yves Chibon napsal(a): > > On Mon, Jul 10, 2017 at 05:17:04PM +0200, Vít Ondruch wrote: > > > Dne 10.7.2017 v 11:23 Pierre-Yves Chibon napsal(a): > > On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote: > > On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > 3. The default landing page for a package shows a message about > the missing readme. Maybe we could show the %description there in > such cases? > > Or as an interim, show the spec file? > > What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ? > > The description comes from the rawhide repo via mdapi. > > Is the mdapi already fixed to provide correct information about > overlapped packages? > > I feel this is a packaging issue. > > > https://apps.fedoraproject.org/packages/ruby > > I don't think it is based on the link above. > > What you are pointing out isn't a problem with mdapi but with fedora-packages > and it is caching the info > > Right, I have no idea how it came to conclusion that rubygems is > subpackage of ruby, this is not true, never was true and never will be > true. Oh I can easily answer this one: - Download: http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite.bz2 - Extract it: bzip2 -d f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite.bz2 - Open the database: sqlite3 f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite - Run the query: SELECT name, arch, version, epoch, release, rpm_sourcerpm FROM packages where name ='rubygems'; Here is the output: rubygems|noarch|2.6.10|0|100.fc27|rubygems-2.6.10-100.fc27.src.rpm rubygems|noarch|2.6.11|0|79.fc27|ruby-2.4.1-79.fc27.src.rpm So in the rpm metadata, there is a rubygems package coming from the ruby source rpm. I can't tell you why the metadata think so, but that's what they contain and thus why mdapi exposes this. > So lets take a look on mdapi: > > https://apps.fedoraproject.org/mdapi/rawhide/pkg/rubygems > > What does the 'basename "rub"' means? One could think that this could be > name of the source package, but honestly, I don't know. I saw this one yesterday, I wonder if this isn't a bug in mdapi eating the last letter (so a y here). > https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby > https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby-libs > > What is the "co-packages" list? It does not make any sense to me looking > at all three links above. The co-packages are supposed to be the packages generated by the source package. > but I also think there is a packaging issue at the > root of this question. > > Overlapping packages is nothing new. And as long as repositories and > depsolver can handle them, there is no problem with them. > > Actually it would be pretty natural if one day rubygems is shown as coming > from rubygems SRPM and the other day it would say it comes from ruby SRPM. > This is how DNF works. But mdapi together with packages are trying to be > smarter. Maybe it would feel natural to you but certainly not to me. mdapi is not smart, quite the opposite, it exposes what is in the sqlite databases of the rpm repositories. If it exposes something odd, it is likely because there is something odd in the databases. But it is constructed around the idea that there is only one package for a given name. > The question is, why there is no trace of "dnf", "libsolv" or "librepo" in > the source code of mdapi. This is what you should use to get reliable > information about packages. mdapi stands for meta-data API, it is not in any way exposing package dependencies, it is purely exposing meta data. > So to update the > description, simply update the package in rawhide. > > You can then simply complement these information with a README file. > > I think there should be something like "fedpkg generate-readme", where > the generated README could contain badges, which would reference BZ, > Koscheji, Koji, whatever else, it could contain the description etc + > some useful development tips. This would be in similar manner GitHub can > display various badges now. The initial README could be generated during > the repository setup. This way, Pagure won't need any specific > fedora-infrastructure hacks. > > Pagure already supports some sort of theming allowing to override templates. > This is the mechanism used to display the information above, so this template > isn't part of pagure itself. > > But you still need to adjust some templates. I am proposing something more > generic. To adjust the README, you don't need any server side template. If you feel strongly about this, I'll welcome any help :) I've done the template, I would be thrilled to not have to maintain it! Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
