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 <https://apps.fedoraproject.org/packages/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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
