|
Dne 11.7.2017 v 11:41 Pierre-Yves
Chibon napsal(a):
On Tue, Jul 11, 2017 at 09:50:31AM +0200, Vít Ondruch wrote: Well, yes. Unfortunately, I said it the other way. But the "packages" states: ~~~ rubySubpackage of rubygems~~~ 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 then there are missing quite some packages. I'll borrow the list from Tom Hughes: ~~~ bericote [~/ruby] % fgrep %package ruby.spec %package devel %package libs %package -n rubygems %package -n rubygems-devel %package -n rubygem-rake %package irb %package -n rubygem-rdoc %package doc %package -n rubygem-bigdecimal %package -n rubygem-did_you_mean %package -n rubygem-io-console %package -n rubygem-json %package -n rubygem-minitest %package -n rubygem-openssl %package -n rubygem-power_assert %package -n rubygem-psych %package -n rubygem-net-telnet %package -n rubygem-test-unit %package -n rubygem-xmlrpc ~~~ This is 19 packages vs 14 packages listed by mdapi. 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. But this is wrong assumption. Repository may contain varaious versions of package. Look at RHEL repositories. Look at Copr. One package per name is just Fedoraism and it is due to space constrains AFAIK. 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. I expect that the metadata will provide the information as my package manager. If the data differs, then there should be really good reason for that. I really don't see point why to manage separate routines to download and parse the metadata when there is available standardized library. 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! Well .... :) Vít |
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
