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:
   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.

Well, yes. Unfortunately, I said it the other way. But the "packages" states:

~~~

ruby

Subpackage 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