[Fwd: Re: [Fedora-packaging] Re: why the Group tag is obsolete ?]

[Sérgio Basto]

Hello, I'd like understand how groups of package are now detect ,
specially in 3rd repo packages  which can't use comps.xml. 

Thanks ! 
-------- Forwarded Message --------
From: Sérgio Basto <sergio(a)serjux.com&gt;
To: packaging(a)lists.fedoraproject.org
Subject: Re: [Fedora-packaging] Re: why the Group tag is obsolete ?
Date: Sun, 28 Aug 2016 07:24:58 +0100

On Seg, 2016-08-01 at 09:17 -0600, Dave Johansen wrote:
>  
>  On Sun, Jul 31, 2016 at 9:23 PM, Sérgio Basto <sergio(a)serjux.com&gt;
>  wrote:
>  > 
>  > Hi, 
>  > A year ago, I learned that Group tag is obsolete [1] I remember ask
>  > the
>  > reason and is something about comps.xml that I don't remember
>  > neither
>  > find on google , but for projects that still use repoview, Group
>  > tag is
>  > needed. So the questions are, have we any replacement for repoview
>  > ? or
>  > another way to show one repo content ? and why the Group tag is
>  > obsolete ? can someone remind me why. And how we now the group of
>  > one
>  > package ? .
>  > 
>  > Thanks.
>  > 
>  > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1239067#c1
>  Here's the FPC ticket about it:
>  https://fedorahosted.org/fpc/ticket/199  
Thanks I was able to find the reason: 

RPM in Fedora 18 does not require the presence of the Group tag in the
spec file. If the tag is defined, it will be ignored. The package
groups of the yum application are used on a Fedora 18 system as the
relevant source of information on which group is the package a part
of. 

I remembered in one thread of devel mailing list on create hawaii group
and bingo found the link: 
https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_...

So now, how I know the group of the package (via yum or dnf) ? seems to
me many packages will not have group ... and 3rd-part software ? 

Also /usr/bin/gnome-software how find the group of the package ? 

Well this is not a very important matter , but I'd like try organize
packages in groups , via repoview.

Thanks.
-- 
Sérgio M. B.

-- 
Sérgio M. B.

[Adam Williamson]

On Thu, 2016-10-27 at 17:24 +0100, Sérgio Basto wrote:
>  Hello, I'd like understand how groups of package are now detect
> ,
>  specially in 3rd repo packages  which can't use comps.xml.  
Sure they can. Third party repos can provide comps, and all Fedora
packaging tools will use it. RPMFusion, for instance, includes comps
data.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Sérgio Basto]

Hi, 

On Qui, 2016-10-27 at 09:30 -0700, Adam Williamson wrote:
>  On Thu, 2016-10-27 at 17:24 +0100, Sérgio Basto wrote:
>  > 
>  > Hello, I'd like understand how groups of package are now detect ,
>  > specially in 3rd repo packages  which can't use comps.xml. 
>  Sure they can. Third party repos can provide comps, and all Fedora
>  packaging tools will use it. RPMFusion, for instance, includes comps
>  data. 
Where ? but my main question is how apper or gnome-software knows the
categories of the packages ? 

-- 
Sérgio M. B.

[Adam Williamson]

On Thu, 2016-10-27 at 17:39 +0100, Sérgio Basto wrote:
>  Hi, 
>  
>  On Qui, 2016-10-27 at 09:30 -0700, Adam Williamson wrote:
>  > On Thu, 2016-10-27 at 17:24 +0100, Sérgio Basto wrote:
>  > > 
>  > > Hello, I'd like understand how groups of package are now detect ,
>  > > specially in 3rd repo packages  which can't use comps.xml. 
>  > 
>  > Sure they can. Third party repos can provide comps, and all Fedora
>  > packaging tools will use it. RPMFusion, for instance, includes comps
>  > data.
>  
>  Where ? but my main question is how apper or gnome-software knows the
>  categories of the packages ?  
Hmm, actually, maybe it currently doesn't, but it definitely has
before:

http://download1.rpmfusion.org/free/fedora/updates/testing/20/x86_64/comp...

But basically, any repo can have comps data and dnf will respect it;
you can set up an external repo with comps data that lists some package
from that repo as being in the `standard` group, for instance, and when
it installs the `standard` group, dnf will include that package. AFAIK
this has always been intended to work. I'm not sure how often it gets
tested.

I think Software's 'groups' are really the 'categories' from the
app's
.desktop file:

https://specifications.freedesktop.org/menu-spec/1.1/ar01s03.html#desktop...

GNOME Software's list of recognized categories isn't exactly the same
as the spec's list of 'registered categories', though:

https://specifications.freedesktop.org/menu-spec/1.1/apa.html
https://git.gnome.org/browse/gnome-software/tree/src/plugins/gs-desktop-c...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Dennis Gilmore]

On jueves, 27 de octubre de 2016 5:39:20 PM CDT Sérgio Basto wrote:
>  Hi, 
>  
>  On Qui, 2016-10-27 at 09:30 -0700, Adam Williamson wrote:
>  > On Thu, 2016-10-27 at 17:24 +0100, Sérgio Basto wrote:
>  > > Hello, I'd like understand how groups of package are now detect ,
>  > > specially in 3rd repo packages  which can't use comps.xml. 
>  > 
>  > Sure they can. Third party repos can provide comps, and all Fedora
>  > packaging tools will use it. RPMFusion, for instance, includes comps
>  > data.
>  
>  Where ? but my main question is how apper or gnome-software knows the
>  categories of the packages ?  
There is a mechanism to refernece the appdata in repomd.xml what is needed is 
to close a gap and make it possible to put the appdata into rpm headers so 
that createrepo can extract the data and make the metadata on the fly. afaik 
the gnome-software folks and rpm folks were going to work on a solution  a 
year or two back and it has not materialised. having to extract files and data 
from inside rpm payloads is expensive, clunky and cumbersome.

Dennis

[Sérgio Basto]

On Qui, 2016-10-27 at 14:07 -0500, Dennis Gilmore wrote:
>  On jueves, 27 de octubre de 2016 5:39:20 PM CDT Sérgio Basto wrote:
>  > 
>  > Hi, 
>  > 
>  > On Qui, 2016-10-27 at 09:30 -0700, Adam Williamson wrote:
>  > > 
>  > > On Thu, 2016-10-27 at 17:24 +0100, Sérgio Basto wrote:
>  > > > 
>  > > > Hello, I'd like understand how groups of package are now detect
>  > > > ,
>  > > > specially in 3rd repo packages  which can't use comps.xml. 
>  > > Sure they can. Third party repos can provide comps, and all
>  > > Fedora
>  > > packaging tools will use it. RPMFusion, for instance, includes
>  > > comps
>  > > data.
>  > Where ? but my main question is how apper or gnome-software knows
>  > the
>  > categories of the packages ? 
>  There is a mechanism to refernece the appdata in repomd.xml what is
>  needed is 
>  to close a gap and make it possible to put the appdata into rpm
>  headers so 
>  that createrepo can extract the data and make the metadata on the
>  fly. afaik 
>  the gnome-software folks and rpm folks were going to work on a
>  solution  a 
>  year or two back and it has not materialised. having to extract files
>  and data 
>  from inside rpm payloads is expensive, clunky and cumbersome. 
Many thanks by your reply, yes or creterepo could use appdata directly,
makes sense improve createrepo with appdata, btw I noticie, apper (kde
software manager) on Fedora 24 fails on search groups with:
 "SearchGroups not supported by backend" , what tools we have to read
appdata ? 

Thanks 

>  Dennis
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 
-- 
Sérgio M. B.

[Kevin Kofler]

Sérgio Basto wrote:
>  Many thanks by your reply, yes or creterepo could use appdata
> directly,
>  makes sense improve createrepo with appdata, btw I noticie, apper (kde
>  software manager) on Fedora 24 fails on search groups with:
>  "SearchGroups not supported by backend" , what tools we have to read
>  appdata ? 
AppData is the source format (that individual packages ship), the metadata 
software installers can actually work on is called AppStream (and is 
periodically generated from the AppData of all packages in the 
distribution).

The KDE software installer using AppStream is called Plasma Discover (or in 
short, just Discover).

Apper cannot browse groups in current Fedora releases because the 
PackageKit-hif backend (still!) does not support the required feature. The 
old PackageKit-yum was able to enumerate comps groups. (Most other 
PackageKit backends implement equivalent functionality, based on whatever 
grouping mechanism the respective distribution uses.) That functionality was 
never implemented in PackageKit-hif.

        Kevin Kofler

[Sérgio Basto]

On Sex, 2016-10-28 at 00:23 +0200, Kevin Kofler wrote:
>  Sérgio Basto wrote:
>  > 
>  > Many thanks by your reply, yes or creterepo could use appdata
>  > directly,
>  > makes sense improve createrepo with appdata, btw I noticie, apper
>  > (kde
>  > software manager) on Fedora 24 fails on search groups with:
>  > "SearchGroups not supported by backend" , what tools we have to
>  > read
>  > appdata ?
>  AppData is the source format (that individual packages ship), the
>  metadata 
>  software installers can actually work on is called AppStream (and is 
>  periodically generated from the AppData of all packages in the 
>  distribution).
>  
>  The KDE software installer using AppStream is called Plasma Discover
>  (or in 
>  short, just Discover).
>  
>  Apper cannot browse groups in current Fedora releases because the 
>  PackageKit-hif backend (still!) does not support the required
>  feature. The 
>  old PackageKit-yum was able to enumerate comps groups. (Most other 
>  PackageKit backends implement equivalent functionality, based on
>  whatever 
>  grouping mechanism the respective distribution uses.) That
>  functionality was 
>  never implemented in PackageKit-hif. 
yeah, so the group tag shouldn't be obsolete , we should use it as
fallback .
 


>          Kevin Kofler
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 
-- 
Sérgio M. B.

[Kevin Kofler]

Sérgio Basto wrote:
>  yeah, so the group tag shouldn't be obsolete , we should use it
> as
>  fallback . 
I don't see how the text you quoted support this in any way. None of the KDE 
tools support the Group tag. (They never did.)

        Kevin Kofler

[Sérgio Basto]

On Sáb, 2016-11-05 at 04:45 +0100, Kevin Kofler wrote:
>  Sérgio Basto wrote:
>  > 
>  > yeah, so the group tag shouldn't be obsolete , we should use it as
>  > fallback .
>  I don't see how the text you quoted support this in any way. None of
>  the KDE 
>  tools support the Group tag. (They never did.) 
OK, so grouping was always based on comps.xml ? (and now also based on
appdata ...) .

Reading https://fedoraproject.org/wiki/New_package_process_for_existing_c...
(...)
Step 14: Add the package to the comps file(s) if appropriate. 
(...)

What package is not appropriate add to comps ? at least we should
specify the group isn't it ? 

So every new package instead have group tag should be add to comps ? 


Thanks to all for all help here and in others places .
-- 
Sérgio M. B.

[Neal Gompa]

On Fri, Nov 4, 2016 at 11:45 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Sérgio Basto wrote:
> > yeah, so the group tag shouldn't be obsolete , we should use it as
> > fallback .
>
>  I don't see how the text you quoted support this in any way. None of the KDE
>  tools support the Group tag. (They never did.)
>  
That's not true. They currently do not with the Fedora backend, but in
the past they did read that information with older backends. And the
KDE tools do read that information with the other RPM backends now.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Neal Gompa wrote:

>  On Fri, Nov 4, 2016 at 11:45 PM, Kevin Kofler wrote:
> > I don't see how the text you quoted support this in any way. None of the
> > KDE tools support the Group tag. (They never did.)
>  
>  That's not true. They currently do not with the Fedora backend, but in
>  the past they did read that information with older backends. And the
>  KDE tools do read that information with the other RPM backends now. 
I should have clarified: They do not and never did in Fedora. PackageKit-yum 
never used RPM groups, always comps. And PackageKit-hif/PackageKit-dnf does 
not implement the group functionality at all.

        Kevin Kofler

[Sérgio Basto]

On Ter, 2016-11-08 at 04:04 +0100, Kevin Kofler wrote:
>  PackageKit-yum 
>  never used RPM groups, always comps 
So, (if we want the package have a group ) all packages should be
enumerated in comps, or not ? . 

Also we have a poor support of groups in dnf, even querytags [1]
haven't group tag to query. 

New question, how I query in what groups of comps a package is ? 

Thanks,

[1] 
dnf repoquery --querytags 
Available query-tags: use --queryformat ".. %{tag} .."

name, arch, epoch, version, release, reponame (repoid), evr
installtime, buildtime, size, downloadsize, installsize
provides, requires, obsoletes, conflicts, sourcerpm
description, summary, license, url

-- 
Sérgio M. B.

[Rex Dieter]

Sérgio Basto wrote:

>  On Ter, 2016-11-08 at 04:04 +0100, Kevin Kofler wrote:
> > PackageKit-yum
> > never used RPM groups, always comps
>  
>  So, (if we want the package have a group ) all packages should be
>  enumerated in comps, or not ? . 
Yes (in comps)

-- Rex