How important is comps.xml to us these days? Which packages should be in comps.xml and which not?

[Thorsten Leemhuis]

Hi all!

I recently created comps.xml files for RPM Fusion. During that a few
things around comps.xml got discussed on the RPM Fusion lists(?).

That and a recent change (?) to
https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
made me wonder:


How important is comps.xml to us these days?


(Note that I mean Fedora and RPM Fusion with "us" here, as RPM Fusion
for things like this just follows the Fedora guidelines)

Comps.xml is afaics mainly used in anaconda (and thus indirectly in
tools like pungi that rely on anaconda) and yum (if you know what to do)
these days; PackageKit afaics doesn't use it much (or does it use
comps.xml at all? Will that change?); it just lists everything it finds
afaics (correct me if I'm wrong, I'm not using PackageKit much and just
use yum directly).

Thus for most packages it doesn't matter much if they are missing in
comps.xml -- if they are missing there they will not be able to select
in anaconda during install, but that's all. Which brings me to the
second question:


Which packages should be in comps.xml and which not?


Round about two years ago (e.g. before the merge) we IIRC for a short
while mainly said and acted like this: round about everything that is
not a lib (those normally get tracked in by deps when needed) or a devel
package should be mentioned in comps.xml; that of course included
command line apps(?). Note sure if it ever made it to the guidelines

If you maintain an application which makes sense for a user to select
during installation, [...] make sure that your package is listed in a
reasonable group in the comps-fn.xml.in files.

I consider the "during installation" part not much helpful because a
package that seems unimportant during installation for 99% of the users
might be something a few other users will look out for. Heck, some new
Fedora users might even abort the Fedora install at this point if they
miss a package they really plan to use with Fedora.

But that is only one of the problems afaics; according to

http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus/CompsF10Missing

there are 2866 packages in comps-f10 and 1711 packages missing (seems
the SRPMS are used as a base here; I'm wondering if using RPMs might be
more wise, but that is just one more thing to discuss); some of
those 1711 really are in fedora for quite a while and really look to me
like worthwhile mentioning in comps.xml (see above), to make sure people
can find and select them right during install with anaconda. Do we care?

Cu
knurd

(?) doesn't matter much for this discussion, but for the curious see
this thread
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-September/001027.html

(?)
https://fedoraproject.org/w/index.php?title=PackageMaintainers%2FCompsXml&diff=49865&oldid=36786

(?) see also
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-September/001103.html

[Ville Skyttä]

Post by Thorsten Leemhuis

If you maintain an application which makes sense for a user to select
during installation, [...] make sure that your package is listed in a
reasonable group in the comps-fn.xml.in files.

I consider the "during installation" part not much helpful

Not sure if you're referring to the addition of those two words, but I added
them today - if I'm missing something and they make the document less
correct, the change should be reverted.

But I thought it'd be better that way than just "If you maintain an
application which makes sense for a user to select, ..." (select when? ever?)

[Thorsten Leemhuis]

Post by Ville Skyttä

Post by Thorsten Leemhuis

If you maintain an application which makes sense for a user to select
during installation, [...] make sure that your package is listed in a
reasonable group in the comps-fn.xml.in files.

I consider the "during installation" part not much helpful

Not sure if you're referring to the addition of those two words, but I added
them today -

I don't have a any problems with the addition of those two words (but
I'm not sure if they really improve the situation); the change OTOH was
one more reason for me to actually write the mail that started this
thread ;-)

Post by Ville Skyttä
if I'm missing something and they make the document less
correct, the change should be reverted.

No pressing need to; what we afaics need is this

1. take a closer look at how the data from comps.xml is used in anaconda
and PackageKit or other software
2. based on those information create more clear guidelines (or even a
policy) what packages should be in comps (and where and how)
3. implement that guideline/policy; that normally will be a job that is
best done by the package maintainers; but I suppose more than just a few
will likely ignore that work, thus depending on how important comps.xml
is (which depends on "1") someone maybe should sit down and add all
those that are not in yet but should;

Post by Ville Skyttä
[...]

CU
knurd

[Rahul Sundaram]

Post by Thorsten Leemhuis
Comps.xml is afaics mainly used in anaconda (and thus indirectly in
tools like pungi that rely on anaconda) and yum (if you know what to do)
these days; PackageKit afaics doesn't use it much (or does it use
comps.xml at all? Will that change?); it just lists everything it finds
afaics (correct me if I'm wrong, I'm not using PackageKit much and just
use yum directly).

PackageKit does use it via the yum backend.

http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/

Rahul

[Kevin Kofler]

Post by Rahul Sundaram
PackageKit does use it via the yum backend.
http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/

Note that this is only from 0.3.3 on. The 0.2.x version currently in Fedora 9
(and the 0.1.x version in F9 GA) just hardcode the categories, which is IMHO a
bug (or "missing feature" if you prefer) in PackageKit, so I'm glad this got
fixed now. For example, the hardcoded category for KDE was missing some of the
stuff we list for KDE in comps, and some categories were missing entirely (e.g.
KDE Software Development).

Kevin Kofler

[Thorsten Leemhuis]

Post by Kevin Kofler

Post by Rahul Sundaram
PackageKit does use it via the yum backend.

One more reason for us then to make sure everything a user might want to
select is in comps.xml, isn't it?

Post by Kevin Kofler

Post by Rahul Sundaram
http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/

Note that this is only from 0.3.3 on.

/me looks at rawhide and finds 0.3.2

/me grabs 0.3.3 straight from koji

/me fails to get it to work on F9 (likely my faul) :-/

Hmm. From the screenshot it's hard to see if gpk-application exports the
package groups from comps.xml similar to how pirut/anaconda do. But
seems to be different, which would be a important detail for the
decision how to maintain the comps.xml in Fedora...

Post by Kevin Kofler
[...]

Cu
knurd

[Thorsten Leemhuis]

Post by Thorsten Leemhuis

Post by Kevin Kofler

Post by Rahul Sundaram
PackageKit does use it via the yum backend.

One more reason for us then to make sure everything a user might want to
select is in comps.xml, isn't it?

Post by Kevin Kofler

Post by Rahul Sundaram
http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/

Note that this is only from 0.3.3 on.

/me looks at rawhide and finds 0.3.2
/me grabs 0.3.3 straight from koji
/me fails to get it to work on F9 (likely my fault) :-/

Updating yum as well did the trick.

Post by Thorsten Leemhuis
Hmm. From the screenshot it's hard to see if gpk-application exports the
package groups from comps.xml similar to how pirut/anaconda do. But
seems to be different, which would be a important detail for the
decision how to maintain the comps.xml in Fedora...

Seems to be way different. In pirut/anaconda you in F9 for example can
select the group "GNOME Desktop Environment"; then you can hit the
"details" button and select some more packages from the gnome group or
deselect some other you don't want. Seems that's not possible in
gpk-application right now. Not sure if it should, but that's quite and
important detail when if comes to the "how to maintain comps.xml
properly" question.

CU
knurd

[Tim Lauridsen]

Post by Thorsten Leemhuis

Post by Thorsten Leemhuis

Post by Kevin Kofler

Post by Rahul Sundaram
PackageKit does use it via the yum backend.

One more reason for us then to make sure everything a user might want
to select is in comps.xml, isn't it?

Post by Kevin Kofler

Post by Rahul Sundaram
http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/

Note that this is only from 0.3.3 on.

/me looks at rawhide and finds 0.3.2
/me grabs 0.3.3 straight from koji
/me fails to get it to work on F9 (likely my fault) :-/

Updating yum as well did the trick.

Post by Thorsten Leemhuis
Hmm. From the screenshot it's hard to see if gpk-application exports
the package groups from comps.xml similar to how pirut/anaconda do.
But seems to be different, which would be a important detail for the
decision how to maintain the comps.xml in Fedora...

Seems to be way different. In pirut/anaconda you in F9 for example can
select the group "GNOME Desktop Environment"; then you can hit the
"details" button and select some more packages from the gnome group or
deselect some other you don't want. Seems that's not possible in
gpk-application right now. Not sure if it should, but that's quite and
important detail when if comes to the "how to maintain comps.xml
properly" question.
CU
knurd

The groups in comps.xml is used as meta-packages, there can be installed
and removed. just like yum groupinstall/groupremove.
Ex. you can install KDE by installing the kde-desktop meta-package.
All the meta-packages (comps groups) are located under collections.
The categories is not used in pk-application.

Tim

[Thorsten Leemhuis]

Post by Tim Lauridsen

Post by Thorsten Leemhuis

Post by Thorsten Leemhuis

Post by Kevin Kofler

Post by Rahul Sundaram
PackageKit does use it via the yum backend.

One more reason for us then to make sure everything a user might want
to select is in comps.xml, isn't it?

Post by Kevin Kofler

Post by Rahul Sundaram
http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/

Note that this is only from 0.3.3 on.

/me looks at rawhide and finds 0.3.2
/me grabs 0.3.3 straight from koji
/me fails to get it to work on F9 (likely my fault) :-/

Updating yum as well did the trick.

Post by Thorsten Leemhuis
Hmm. From the screenshot it's hard to see if gpk-application exports
the package groups from comps.xml similar to how pirut/anaconda do.
But seems to be different, which would be a important detail for the
decision how to maintain the comps.xml in Fedora...

Seems to be way different. In pirut/anaconda you in F9 for example can
select the group "GNOME Desktop Environment"; then you can hit the
"details" button and select some more packages from the gnome group or
deselect some other you don't want. Seems that's not possible in
gpk-application right now. Not sure if it should, but that's quite and
important detail when if comes to the "how to maintain comps.xml
properly" question.

The groups in comps.xml is used as meta-packages, there can be installed
and removed. just like yum groupinstall/groupremove.

Yeah, but that will only install (or remove?) packages that are
'<packagereq type="default">' in the comps file, correct?

Post by Tim Lauridsen
Ex. you can install KDE by installing the kde-desktop meta-package.
All the meta-packages (comps groups) are located under collections.
The categories is not used in pk-application.

IOW: adding packages to a group in comps.xml as '<packagereq
type="optional">' is only worth the trouble if you want to make the
package selectable in anaconda, as that information is not used by
pk-application. Correct?

CU
knurd

[Kevin Kofler]

Post by Tim Lauridsen
The groups in comps.xml is used as meta-packages, there can be installed
and removed. just like yum groupinstall/groupremove.
Ex. you can install KDE by installing the kde-desktop meta-package.
All the meta-packages (comps groups) are located under collections.
The categories is not used in pk-application.

I see this now in the screenshot. I'm sorry, but I think this is a really,
really awful UI. Comps groups should be shown as categories, in the list view
on the left, instead of the current hardcoded categories.

As you'll certainly ask me why, i.e. what's wrong with the current
implementation, here's it: With the current UI:
* there is no way to see what's in the collection,
* we still rely on the hardcoded categories which can't be controlled by the
distribution's package maintainers and which are missing a lot of stuff from
comps.xml, when we actually _do_ have that information and mostly throw it
away,
* it is inconsistent: both the comps.xml groups and the hardcoded categories
are lists of packages, yet the hardcoded categories can be listed, but not
installed or removed as a whole, the comps.xml groups on the other hand are
listed as packages and can be installed or removed, but there's no way to list
their contents.

IMHO, a much better approach would be to:
* throw out the hardcoded categories! We have that information in comps.xml,
PackageKit should not try to duplicate it.
* display the comps.xml groups instead of the hardcoded categories and
* add tristate checkboxes next to the groups, like in Anaconda: by default,
they're in the gray state, unless you have all packages installed (checked) or
none (unchecked); they can be checked or unchecked, which is equivalent to a
groupinstall or groupremove, but the only way to get them into the gray state
is to individually install or remove packages from the group (using the list
view on the right).

Kevin Kofler

[Thorsten Leemhuis]

Post by Kevin Kofler
[...]
* throw out the hardcoded categories! We have that information in comps.xml,
PackageKit should not try to duplicate it.
* display the comps.xml groups instead of the hardcoded categories and
* add tristate checkboxes next to the groups, like in Anaconda: by default,
they're in the gray state, unless you have all packages installed (checked) or
none (unchecked); they can be checked or unchecked, which is equivalent to a
groupinstall or groupremove, but the only way to get them into the gray state
is to individually install or remove packages from the group (using the list
view on the right).

Strong +1 with one addition for us:

* Fedora and its package maintainers need to way better job making sure
that most if not all packages are properly listed in comps.xml --
otherwise a good portion of our packages won't show up in any of the groups

CU
knurd

[Nicolas Mailhot]

Post by Thorsten Leemhuis

Post by Kevin Kofler
[...]
* throw out the hardcoded categories! We have that information in comps.xml,
PackageKit should not try to duplicate it.

The PK argument used to be comps groups suck, are distro-specific, have
no equivalent on some distros, so people should drop comps and
contribute to pk hardcoded stuff instead.

NIH syndrom IMHO, replacing distro infra with something else, which pk
was not supposed to do. (also pk hardcoding makes no provision for
non-centralised group declaration)

Post by Thorsten Leemhuis

Post by Kevin Kofler
* add tristate checkboxes next to the groups, like in Anaconda: by default,
they're in the gray state, unless you have all packages installed (checked) or
none (unchecked);

Mostly, pk needs to learn optionals

Post by Thorsten Leemhuis
* Fedora and its package maintainers need to way better job making sure
that most if not all packages are properly listed in comps.xml --
otherwise a good portion of our packages won't show up in any of the groups

Do not generalise, some Fedora groups do have clear comps policies
(though no one really wanted to approve those)
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080922/a299347f/attachment.bin

[Richard Hughes]

Post by Nicolas Mailhot
The PK argument used to be comps groups suck, are distro-specific,
have no equivalent on some distros, so people should drop comps and
contribute to pk hardcoded stuff instead.

Sure. PK groups are different to comps groups. There are tons of comps
groups, and I wanted only a few that we can share between distros. There
are other distros than fedora that will share these categories.

Post by Nicolas Mailhot
NIH syndrom IMHO

NSFU (not suitable for us) actually.

Richard.

[Jesse Keating]

Post by Richard Hughes
NSFU (not suitable for us) actually.

What's your definition of "us"? Showing the users one set of package
information during install, and then a completely different one after
install is not suitable either.

Is "not suitable for us" supposed to mean that PK is trying to hard to
be generic across the distros so that we lose the classifications and
groupings we work on in Fedora, so that PK is not suitable for Fedora?
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080922/6a556d56/attachment.bin

[Richard Hughes]

Post by Jesse Keating

Post by Richard Hughes
NSFU (not suitable for us) actually.

What's your definition of "us"? Showing the users one set of package
information during install, and then a completely different one after
install is not suitable either.

Surely with a live CD we don't show the user any sets of groups at all?

Post by Jesse Keating
Is "not suitable for us" supposed to mean that PK is trying to hard to
be generic across the distros so that we lose the classifications and
groupings we work on in Fedora, so that PK is not suitable for Fedora?

No, we keep the groupings as the yum backend supports them as part of
"collections". I'm just not showing the giant tree of arbitrary
classifications as the main point of user interaction.

Richard.

[Kevin Kofler]

Post by Richard Hughes

Post by Jesse Keating
What's your definition of "us"? Showing the users one set of package
information during install, and then a completely different one after
install is not suitable either.

Surely with a live CD we don't show the user any sets of groups at all?

But that's not the only way to install Fedora.

Post by Richard Hughes

Post by Jesse Keating
Is "not suitable for us" supposed to mean that PK is trying to hard to
be generic across the distros so that we lose the classifications and
groupings we work on in Fedora, so that PK is not suitable for Fedora?

No, we keep the groupings as the yum backend supports them as part of
"collections". I'm just not showing the giant tree of arbitrary
classifications as the main point of user interaction.

Those "arbitrary" classifications are what Fedora maintainers work hard to keep
up to date and complete, unlike your incomplete hardcoded classifications in
PackageKit which are truly arbitrary and do not reflect how Fedora intends to
categorize its packages.

It doesn't make sense to have distro-independent categories of packages,
categories are defined by the distributions, they should be read from the
appropriate distro-specific classification by the PackageKit backend. For
example, does it make sense to show a KDE resp. GNOME category for a
distribution which doesn't even ship KDE resp. GNOME, maybe with a single
package (think of a GNOME distribution shipping e.g. Amarok or K3b as its only
KDE app)? And distributions with more packages will necessarily have more
categories! Fedora has many packages, PackageKit's categories don't even come
close to covering all of them.

Kevin Kofler

[Matthias Clasen]

Post by Kevin Kofler
Those "arbitrary" classifications are what Fedora maintainers work hard to keep
up to date and complete, unlike your incomplete hardcoded classifications in
PackageKit which are truly arbitrary and do not reflect how Fedora intends to
categorize its packages.

What makes you think that the comps classifications are less arbitrary ?
And isn't one of the original motivations for this thread that many
packagers are exactly _not_ doing that hard work ?!

[James Antill]

Post by Matthias Clasen

Post by Kevin Kofler
Those "arbitrary" classifications are what Fedora maintainers work hard to keep
up to date and complete, unlike your incomplete hardcoded classifications in
PackageKit which are truly arbitrary and do not reflect how Fedora intends to
categorize its packages.

What makes you think that the comps classifications are less arbitrary ?

Because anyone who sets up a repository can create a classification,
instead of making it a "oh, you've created a new package ... now you
just need to recompile PK".

Post by Matthias Clasen
And isn't one of the original motivations for this thread that many
packagers are exactly _not_ doing that hard work ?!

Right, so the obvious solution is to make it even harder for anyone to
do anything.

[Nicolas Mailhot]

Post by Matthias Clasen

Post by Kevin Kofler
Those "arbitrary" classifications are what Fedora maintainers work hard to keep
up to date and complete, unlike your incomplete hardcoded classifications in
PackageKit which are truly arbitrary and do not reflect how Fedora intends to
categorize its packages.

What makes you think that the comps classifications are less arbitrary ?
And isn't one of the original motivations for this thread that many
packagers are exactly _not_ doing that hard work ?!

Some of them are. Even if hiding them in our main gui update tool isn't
exactly motivating.
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080923/d2133d32/attachment.bin

[James Antill]

Post by Richard Hughes
No, we keep the groupings as the yum backend supports them as part of
"collections". I'm just not showing the giant tree of arbitrary
classifications as the main point of user interaction.

gpk-application 0.2.5/0.3.2 list 20 hardcoded "groups", including such
joys as "Legacy".

yum grouplist has 45 with just Fedora-9, and 46 if you include the
updates repo. (we added "SUGAR Desktop Environment" -- listed in the
"Other" group in PK, not even the "Other desktops").

Most of the difference seems to be:

1. PK doesn't have any of the '*Development*' groups (9),
2. PK has a single Servers group instead of each of the specific servers
groups (9).

...also PK doesn't have any of the specific groups like "Authoring and
Publishing", "Engineering and Scientific" or amusingly "Fedora
Packager". It also screws up the "*Legacy*" groups putting the legacy
fonts in the Fonts group, for example.

In short it's arbitrarily different, hardcoded and just plain wrong.
But hey, you've done "substantial user research" while we're just lowly
developers, so feel free to keep ignoring us.

Post by Richard Hughes
None of the people in
http://www.packagekit.org/pk-profiles.html could tell me what they
expected to find in base-system/system-tools or
base-system/admin-tools,
or tell me the difference between them.

_Well done_ for bringing up rpm specfile groups which are obsolete, as
I'm sure you know, and have been since before PK existed.
--
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080923/e1833d2f/attachment.bin

[Tim Lauridsen]

I think this discussion is getting a little heated and it is not the
most constructive, if you want something to change IMHO.

I agree in there is some issues with the static groups currently in pk.
so i have made this proposal on the upstream packagekit list.

http://lists.freedesktop.org/archives/packagekit/2008-September/003675.html

To solve some of the issues being discussed in this thread.

Tim

[Thorsten Leemhuis]

Post by Tim Lauridsen
I think this discussion is getting a little heated and it is not the
most constructive, if you want something to change IMHO.
I agree in there is some issues with the static groups currently in pk.
so i have made this proposal on the upstream packagekit list.
http://lists.freedesktop.org/archives/packagekit/2008-September/003675.html
To solve some of the issues being discussed in this thread.

As the one that started this thread (which I didn wasn't meant to become
a PK-bashing (sub-)thread) let me say: thx Tim for working towards a
better solution.


BTW, not sure if it matters, but might be a good time to bring it up:

Livna/RPM Fusion in the past tried to put its packages into the same
groups as Fedora did. That somehow broke or confused groupinstall in yum
iirc (never looked into the details; just heard it from skvidal and
others); thus instead of trying to extend the groups Fedora defined we
now define our own -- e.g. the groups have a different "groupid" and a
string like "(RPM Fusion free)" got added to each of the groups
descriptions(?).

That IMHO might have been fine as a short term solution. But IMHO it's
the wrong thing to do (especially should PK use dynamic groups), as the
user normally should not have to care at all where a package comes from.
Not sure what's the best way to fix this.

Cu
knurd


(?) for the curious: comps.xml files for RPM Fusion can be found at
http://cvs.rpmfusion.org/viewvc/comps/comps-f10.xml.in?root=free&view=markup
http://cvs.rpmfusion.org/viewvc/comps/comps-f10.xml.in?root=nonfree&view=markup

[Jesse Keating]

Post by Thorsten Leemhuis
Livna/RPM Fusion in the past tried to put its packages into the same
groups as Fedora did. That somehow broke or confused groupinstall in yum
iirc (never looked into the details; just heard it from skvidal and
others)

I do believe the problem was that you used the same group names, but
different descriptions. If you had used the exact same
name/description/translation/etc... and /only/ changed the package
contents it would have been just fine. (that's what we do with the
groupdata in the release repos and the updates repos. Only the package
items change, nothing else)
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080923/9389548f/attachment.bin

[Thorsten Leemhuis]

Post by Jesse Keating

Post by Thorsten Leemhuis
Livna/RPM Fusion in the past tried to put its packages into the same
groups as Fedora did. That somehow broke or confused groupinstall in yum
iirc (never looked into the details; just heard it from skvidal and
others)

I do believe the problem was that you used the same group names, but
different descriptions.

I'm quite sure I started with the same group names. But:

- maybe the Fedora names changed over time (I suppose the comps.xml I
used as a start for livna might have been for FC6 or something like
that) and we forgot to adjust our
- we iirc hadn't imported all the translation files (are they under a
free license?), which I suppose might be the root case for the problem

Well, doesn't matter much now. I'm more interested in the way forward.
So what would you suggest that RPM Fusion does in the future? Import the
.po files from fedora to our cvs, adjust the group description and
grouid in our comps files to match the ones from Fedora and make sure
they stay in sync(?)?

(?) the latter shouldn't be to hard to do, but nevertheless is a bit
error prone over time...

Post by Jesse Keating
If you had used the exact same
name/description/translation/etc... and /only/ changed the package
contents it would have been just fine.

Just wondering and making sure I get this right: What exactly do you
mean by "changed" in the latter sentence?

(1) just use the same ids and description and list only the packages
from RPM Fusion in the rpmfusion comps.xml files

(2) import the whole comps.xml stuff from Fedora, keep it in sync and
add the RPM Fusion packages

I suppose you meant (1)?

Post by Jesse Keating
[...]

CU
knurd

P.S.: Why the heck hasn't anybody told me the above when I asked for a
better way to fix the mess livna created a few months ago?

[Jesse Keating]

Post by Thorsten Leemhuis
Just wondering and making sure I get this right: What exactly do you
mean by "changed" in the latter sentence?
(1) just use the same ids and description and list only the packages
from RPM Fusion in the rpmfusion comps.xml files
(2) import the whole comps.xml stuff from Fedora, keep it in sync and
add the RPM Fusion packages
I suppose you meant (1)?

I think I misspoke on the translation side, that likely doesn't matter.
James gave a better description of what happened.

I'd recommend using 1 if you want your packages to show up along side
other Fedora packages in the same groups.

I think this doesn't solve an issue where you add the Livna repo at
install time in anaconda, as there may still be a bug that the group
memberships don't get re-evaluated when a new repo is added, so the
livna group members may not be added to the install list. That's just a
bug though and could probably be fixed.

Post by Thorsten Leemhuis

[...]

CU
knurd
P.S.: Why the heck hasn't anybody told me the above when I asked for a
better way to fix the mess livna created a few months ago?

I'd have to dig through IRC logs, but I'm pretty sure I stated exactly
what you did in #1, along the lines of "either use the same
name/description as Fedora proper does, or use your own group names".
It seemed to me that livna chose the latter and the problem was
"solved".
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080923/d8675ed0/attachment.bin

[Jeremy Katz]

Post by Jesse Keating
I think this doesn't solve an issue where you add the Livna repo at
install time in anaconda, as there may still be a bug that the group
memberships don't get re-evaluated when a new repo is added, so the
livna group members may not be added to the install list. That's just a
bug though and could probably be fixed.

It actually should be fixed with a patch I have queued up for post-beta
that takes care of some other oddities that now pop-up with the ability
to change your base repo. It just felt a little bit too scary to drop
in the day before we froze for beta

Jeremy

[Thorsten Leemhuis]

Post by Jeremy Katz

Post by Jesse Keating
I think this doesn't solve an issue where you add the Livna repo at
install time in anaconda, as there may still be a bug that the group
memberships don't get re-evaluated when a new repo is added, so the
livna group members may not be added to the install list. That's just a
bug though and could probably be fixed.

It actually should be fixed with a patch I have queued up for post-beta
that takes care of some other oddities that now pop-up with the ability
to change your base repo. It just felt a little bit too scary to drop
in the day before we froze for beta

Thx jeremy; and I had assumed the bug in question had been forgotten. Sorry.

CU
knurd

[Thorsten Leemhuis]

Post by Jesse Keating

Post by Thorsten Leemhuis
Just wondering and making sure I get this right: What exactly do you
mean by "changed" in the latter sentence?
(1) just use the same ids and description and list only the packages
from RPM Fusion in the rpmfusion comps.xml files
(2) import the whole comps.xml stuff from Fedora, keep it in sync and
add the RPM Fusion packages
I suppose you meant (1)?

I think I misspoke on the translation side, that likely doesn't matter.
James gave a better description of what happened.
I'd recommend using 1 if you want your packages to show up along side
other Fedora packages in the same groups.

I'll give it a try in RPM Fusions devel branch; we can easily switch it
back later if needed.

Post by Jesse Keating
I think this doesn't solve an issue where you add the Livna repo at
install time in anaconda, as there may still be a bug that the group
memberships don't get re-evaluated when a new repo is added, so the
livna group members may not be added to the install list. That's just a
bug though and could probably be fixed.

https://bugzilla.redhat.com/show_bug.cgi?id=239167

Was closed as WONTFIX :-/ So I suppose that bug is still around in
anaconda. We really need to get this fixed because otherwise it's
impossible to get the rpmfusion-release package automatically installed
for people that enable RPM Fusion during install with anaconda. Which
makes the whole idea to enable a repo during install mostly useless IMHO....

That brings me to a different question: what's the long term solution
for package selection in anaconda? It's a bit odd to offer the old pirut
frontend in anaconda during install and having a frontend for PK later
on the installed system that looks quite different...

Post by Jesse Keating

Post by Thorsten Leemhuis
P.S.: Why the heck hasn't anybody told me the above when I asked for a
better way to fix the mess livna created a few months ago?

I'd have to dig through IRC logs, but I'm pretty sure I stated exactly
what you did in #1, along the lines of "either use the same
name/description as Fedora proper does, or use your own group names".
It seemed to me that livna chose the latter and the problem was
"solved".

Someone else IIRC suggested that renaming was the better way to solve
the problem, and thus that was what I did. But whatever, that is history
now or will be soon, so it doesn't matter much anymore (and I don't care).

CU
knurd

[Thorsten Leemhuis]

Post by Thorsten Leemhuis

Post by Jesse Keating

Post by Thorsten Leemhuis
Just wondering and making sure I get this right: What exactly do you
mean by "changed" in the latter sentence?
(1) just use the same ids and description and list only the packages
from RPM Fusion in the rpmfusion comps.xml files
(2) import the whole comps.xml stuff from Fedora, keep it in sync and
add the RPM Fusion packages
I suppose you meant (1)?

I think I misspoke on the translation side, that likely doesn't matter.
James gave a better description of what happened.
I'd recommend using 1 if you want your packages to show up along side
other Fedora packages in the same groups.

I'll give it a try in RPM Fusions devel branch; we can easily switch it
back later if needed.

Done, but only for the "free" repo for now; new comps can be found for
review in CVS for RPM Fusion:
http://cvs.rpmfusion.org/viewvc/comps/comps-f10.xml.in?root=free&view=markup

File is on the way to the repo and should be available at
http://download1.rpmfusion.org/free/fedora/development/<arch>/os/comps.xml
in a few minutes.

James, Jesse, does that look like it should look like?

Some questions:

- Should I better remove the fields "<_name>", "<_description>"
"<default>" and "<uservisible>" to avoid mixing up what comes from
Fedora's comps.xml?

- I don't define any category's; is that okay?

CU
knurd

[Jesse Keating]

Post by Thorsten Leemhuis
Done, but only for the "free" repo for now; new comps can be found for
http://cvs.rpmfusion.org/viewvc/comps/comps-f10.xml.in?root=free&view=markup
File is on the way to the repo and should be available at
http://download1.rpmfusion.org/free/fedora/development/<arch>/os/comps.xml
in a few minutes.
James, Jesse, does that look like it should look like?

I think so. The real test is what does yum/anaconda see with these
repos. Ideally it'd just be one instance of each group, with all the
right content of the combined repos.

Post by Thorsten Leemhuis
- Should I better remove the fields "<_name>", "<_description>"
"<default>" and "<uservisible>" to avoid mixing up what comes from
Fedora's comps.xml?

I'm honestly not sure what will happen. Worth testing I suppose. It
may not work too well if people use the repo alone without a matching
Fedora repo. Of course, that would be silly to do, but meh...

Post by Thorsten Leemhuis
- I don't define any category's; is that okay?

I think that's fine, provided again that the user uses a Fedora repo
with it to pick up that missing grouping information.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080929/5065399b/attachment.bin

[Thorsten Leemhuis]

Post by Jesse Keating

Post by Thorsten Leemhuis
Done, but only for the "free" repo for now; new comps can be found for
http://cvs.rpmfusion.org/viewvc/comps/comps-f10.xml.in?root=free&view=markup
File is on the way to the repo and should be available at
http://download1.rpmfusion.org/free/fedora/development/<arch>/os/comps.xml
in a few minutes.
James, Jesse, does that look like it should look like?

I think so. The real test is what does yum/anaconda see with these
repos. Ideally it'd just be one instance of each group, with all the
right content of the combined repos.
[...]

Thx for your comments Jesse. I'll give it a try over the next few days
when I got some other things for RPM Fusion sorted out. If somebody else
wants to try what happens in anaconda right now: go for it!

CU
knurd

[James Antill]

Post by Thorsten Leemhuis
Livna/RPM Fusion in the past tried to put its packages into the same
groups as Fedora did.

No, groups are defined by their groupid, Livna always created searate
groups (they had a different ID) ... they just named them the same. This
caused problems on older yum's because on groupinstall yum would pick a
single match so the other group was basically unavailable.
Newer yum's find all groups that match, so there's no problem on
current Fedora 9 or newer.

Of course to be fair reinventing the groups concept in PK, poorly and
with no input from anyone else or ability for Livna to group anything,
also solves this problem.

[Thorsten Leemhuis]

Post by James Antill

Post by Thorsten Leemhuis
Livna/RPM Fusion in the past tried to put its packages into the same
groups as Fedora did.

No, groups are defined by their groupid, Livna always created searate
groups (they had a different ID) ... they just named them the same.

The old and unmodified comps.xml for FC6 is still available
http://livna-dl.reloumirrors.net/fedora/6/i386/comps.xml

The <id>-fields back then were round about those Fedora still uses these
days -- take "<id>sound-and-video</id>" for example; but maybe something
else was from with those files...; I only changed those to be livna
specific for F7 and later a few months ago on request from Fedora
skvidal when the problem that was mentioned earlier showed up

Post by James Antill
[...]
Newer yum's find all groups that match, so there's no problem on
current Fedora 9 or newer.

Good to know, thx.

Post by James Antill
[...]

CU
knurd

[Richard Hughes]

Post by Tim Lauridsen
I think this discussion is getting a little heated and it is not the
most constructive, if you want something to change IMHO.

Tim is spot on, and a good example of someone that does things properly
rather than just ranting about how broken $something is. I really can't
believe how rude some people are on this list.

We spent a few hours over the last week or so on the upstream PackageKit
mailing list, designing a new method and signal to allow us to return
custom groups in a cross distro way.

Tim wrote the initial patch, which I then rewrote a little, and then the
very next day Tim committed a simple yum implementation of the new
method call. All in all it was a few hundred lines added.

Post by Tim Lauridsen
I agree in there is some issues with the static groups currently in
pk.so i have made this proposal on the upstream packagekit list.
http://lists.freedesktop.org/archives/packagekit/2008-September/003675.html

And the end result is something like this:
Loading Image...

It needs some UI review and testing, but it shows how quickly we could
add a feature. The "simple" menu will be show by default, but it'll be
simple to turn on the "advanced" group selector.

Richard.

[Dimi Paun]

This post might be inappropriate. Click to display it.

[Jesse Keating]

Post by Dimi Paun
Nice. But I would get rid of "Window Managers" from under
"Desktop Environments" if we can, it's at the wrong abstraction
level and no regular user will figure out what the heck it
means. It just complicates the options.
In this day and age, customizing the window manager is something that
the hard-core hacker would do...

That would be a change necessary at the Fedora comps level. Patches?
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20081007/dd354cae/attachment.bin

[Thorsten Leemhuis]

Post by Richard Hughes

Post by Tim Lauridsen
I think this discussion is getting a little heated and it is not the
most constructive, if you want something to change IMHO.

Tim is spot on,

Tim, Richard, many thanks for your great work! Much appreciated!

Post by Richard Hughes
and a good example of someone that does things properly
rather than just ranting about how broken $something is.

Remember, we have a lot of skilled people here on the list -- not all of
them are programmers (disclaimer: I'm one of them), but nevertheless
they afaics do a lot of important work for Fedora (art, bugtracking,
getting things organized and dozens of other areas...); they of course
sometimes want to share there option on things that happen in area they
are normally not working -- I think that's a good think and you are IMHO
discouraging those people way to much with sentences like that.

Post by Richard Hughes
I really can't believe how rude some people are on this list.

I would not call it rude. Most if not all of us that participate in
discussions care of Fedora and want to see it improved. But the people
of course disagree about how that is done -- that sometimes lead to hot
discussions, just like two people that are married for a quite a while
(and what to stay married) sometimes have a heated conflict ;-)

And communicating by mail makes things a whole lot more complicated and
worse afaics, as that form of communication sometimes simply doesn't
work well -- especially if people are not very careful (and all of us
sometimes are not careful enough afaics).

Post by Richard Hughes
[...]

Post by Tim Lauridsen
I agree in there is some issues with the static groups currently in
pk.so i have made this proposal on the upstream packagekit list.
http://lists.freedesktop.org/archives/packagekit/2008-September/003675.html

http://rhughes.fedorapeople.org/gpk-groups-comps.png

Looks great. BTW, is this targeted for 0.3.x or 0.4.x?.

But nevertheless please allow me to ask one thing: You said "Tri-state
checkboxes are a disaster" last month on this list. I don't doubt that.
But nevertheless they in Pirut make something possible that is (afaics
from the screenshot; it was not obvious where that code lives, otherwise
I#d taken a closer look myself) not possible with PK: get a whole bunch
of apps (e.g. get KDE with one click if you installed the Gnome spin)
installed or uninstalled by (de)selecting just one checkbox.

It IMHO would be nice to have such kind of function in PK as well. Is
that still there somewhere? Maybe something like the additional "Package
Collections" ( Loading Image...
; second entry on the left side) could still work together with the new
scheme? Then users can select the default set of a group there; most
will not even notive that the collection names are the same as the
names for the package group.

Post by Richard Hughes
[...]

CU
knurd

[Richard Hughes]

Post by Thorsten Leemhuis

Post by Richard Hughes
I really can't believe how rude some people are on this list.

And communicating by mail makes things a whole lot more complicated and
worse afaics, as that form of communication sometimes simply doesn't
work well -- especially if people are not very careful (and all of us
sometimes are not careful enough afaics).

Sure, I totally agree. When writing an email my rule of thumb is to read
the sentence aloud and think "would I say this to someone on the phone"?
-- It's very easy to call software a piece of crap on a mailing list,
but not so easy when you're talking to the author in person :-)

Post by Thorsten Leemhuis
Looks great. BTW, is this targeted for 0.3.x or 0.4.x?.

0.3.7, should be in rawhide on Monday.

Post by Thorsten Leemhuis
But nevertheless please allow me to ask one thing: You said "Tri-state
checkboxes are a disaster" last month on this list. I don't doubt that.
But nevertheless they in Pirut make something possible that is (afaics
from the screenshot; it was not obvious where that code lives, otherwise
I#d taken a closer look myself) not possible with PK: get a whole bunch
of apps (e.g. get KDE with one click if you installed the Gnome spin)
installed or uninstalled by (de)selecting just one checkbox.

Sure, I still think tri-state checkboxes are a disaster.

Post by Thorsten Leemhuis
It IMHO would be nice to have such kind of function in PK as well. Is
that still there somewhere? Maybe something like the additional "Package
Collections" ( http://www.packagekit.org/img/gpk-application-search.png
; second entry on the left side) could still work together with the new
scheme?

Yes, good idea. Collections should be installable for both menu types.

Post by Thorsten Leemhuis
Then users can select the default set of a group there; most
will not even notive that the collection names are the same as the
names for the package group.

Right.

Thanks for the feedback,

Richard.

[Michel Salim]

Post by James Antill
_Well done_ for bringing up rpm specfile groups which are obsolete, as
I'm sure you know, and have been since before PK existed.

I've been wondering -- is there any reason we don't get rpmbuild to
strip the group out of the package metadata when it generates a binary
RPM?

Also, right now, rpmdev-newspec still creates a Group field, and even
prepopulates it for certain templates (e.g. libraries)

Regards,

[Rahul Sundaram]

Post by Michel Salim

Post by James Antill
_Well done_ for bringing up rpm specfile groups which are obsolete, as
I'm sure you know, and have been since before PK existed.

I've been wondering -- is there any reason we don't get rpmbuild to
strip the group out of the package metadata when it generates a binary
RPM?

Smart, Apt and probably others still rely on those IIRC. If they are
taught to use comps, we can get rid of the rpm groups.

Rahul

[Jesse Keating]

Post by Rahul Sundaram
Smart, Apt and probably others still rely on those IIRC. If they are
taught to use comps, we can get rid of the rpm groups.

No, we won't be waiting for those to catch up.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080925/65578e73/attachment.bin

[seth vidal]

Post by Michel Salim

Post by James Antill
_Well done_ for bringing up rpm specfile groups which are obsolete, as
I'm sure you know, and have been since before PK existed.

I've been wondering -- is there any reason we don't get rpmbuild to
strip the group out of the package metadata when it generates a binary
RPM?
Also, right now, rpmdev-newspec still creates a Group field, and even
prepopulates it for certain templates (e.g. libraries)

it'll be maintained for compat reasons by it is no longer required to
build a package as of the new rpm in rawhide, iirc.

-sv

[Panu Matilainen]

Post by seth vidal

Post by Michel Salim

Post by James Antill
_Well done_ for bringing up rpm specfile groups which are obsolete, as
I'm sure you know, and have been since before PK existed.

I've been wondering -- is there any reason we don't get rpmbuild to
strip the group out of the package metadata when it generates a binary
RPM?
Also, right now, rpmdev-newspec still creates a Group field, and even
prepopulates it for certain templates (e.g. libraries)

it'll be maintained for compat reasons by it is no longer required to
build a package as of the new rpm in rawhide, iirc.

Yup. We can't drop off the group tag just like that, not only various
software expects it to be there, it's documented as a mandatory field in
LSB.

rpmbuild no longer requires the Group: tag in specs, but it drops in
"Unspecified" if the spec doesn't set it to comply (the current rawhide
rpm wont do this but it's fixed upstream, rawhide will get it in next
version update)

- Panu -

[Kevin Kofler]

Post by Jesse Keating
Is "not suitable for us" supposed to mean that PK is trying to hard to
be generic across the distros so that we lose the classifications and
groupings we work on in Fedora, so that PK is not suitable for Fedora?

I agree that that's about the only conclusion we can draw.

Kevin Kofler

[Richard Hughes]

Post by Kevin Kofler

Post by Jesse Keating
Is "not suitable for us" supposed to mean that PK is trying to hard to
be generic across the distros so that we lose the classifications and
groupings we work on in Fedora, so that PK is not suitable for Fedora?

I agree that that's about the only conclusion we can draw.

I get the impression you don't like PackageKit, which is fine, but I
would prefer you stick to helpful suggestions and working _WITH_
upstream rather than dictating what upstream HAS to do according to you.

Richard.

[Kevin Kofler]

Post by Richard Hughes
Sure. PK groups are different to comps groups. There are tons of comps
groups, and I wanted only a few that we can share between distros. There
are other distros than fedora that will share these categories.

But those "tons of comps groups" need to be shown! For example PackageKit isn't
showing the KDE Software Development group at all. We need that group shown
(and as a group, not a metapackage).

Kevin Kofler

[Richard Hughes]

Post by Kevin Kofler
But those "tons of comps groups" need to be shown! For example
PackageKit isn't showing the KDE Software Development group at all. We
need that group shown (and as a group, not a metapackage).

You think we NEED a "KDE Software Development group". PackageKit is not
designed for you. Can you explain how having fine grained groups would
help people like: http://www.packagekit.org/pk-profiles.html ?

PackageKit is not designed for the sort of users who are comfortable
using yum on the command line. PackageKit doesn't replace yum, it's just
complimentary. If we designed PK as a "suitable for any user" tool then
it would be suitable for no-one. Hence the need for a profiles page.

Thanks,

Richard.

[Kevin Kofler]

Post by Richard Hughes
You think we NEED a "KDE Software Development group". PackageKit is not
designed for you. Can you explain how having fine grained groups would
help people like: http://www.packagekit.org/pk-profiles.html ?

Well, at least the med student could have a use for a "medical applications"
group (which I'm aware does not currently exist, but that's not PackageKit's
problem ;-) ), if not now, at least in the future. And you have only 3
profiles, that's a pretty small sample of all the users around, I'm sure there
are many more users with needs for at least one specialized group (with the end
result that _all_ specialized groups are needed).

Post by Richard Hughes
PackageKit is not designed for the sort of users who are comfortable
using yum on the command line. PackageKit doesn't replace yum, it's just
complimentary.

Power users can benefit a lot from a UI which is designed with them in mind. I
don't consider this "design for newbies only, power users can just use the
command line" premise helpful.

Post by Richard Hughes
If we designed PK as a "suitable for any user" tool then
it would be suitable for no-one. Hence the need for a profiles page.

That's an assumption which has yet to be proven. For example, KDE aims at being
usable both by new users and by power users and is IMHO fairly successful at
that.

And another issue is that the library design doesn't allow making a more
powerful UI on top of the same library, because the "simple" groups are
hardcoded and there's no API to get to the actual groups. Even if we accept
your premise that a package manager for power users necessarily has to be a
different application, it would still be nice to be able to build it on the
same library. Reinventing the wheel to work around library limitations would be
a big waste. For example, KPackageKit could potentially be that "more powerful
UI" if the library allowed it.

Kevin Kofler

[Richard Hughes]

Post by Kevin Kofler

Post by Richard Hughes
You think we NEED a "KDE Software Development group". PackageKit is not
designed for you. Can you explain how having fine grained groups would
help people like: http://www.packagekit.org/pk-profiles.html ?

Well, at least the med student could have a use for a "medical applications"
group (which I'm aware does not currently exist, but that's not PackageKit's
problem ;-) )

A simple collection (one package) would solve that need, rather than a
whole group of packages that she wouldn't know what any of them did.

Post by Kevin Kofler
, if not now, at least in the future. And you have only 3
profiles, that's a pretty small sample of all the users around, I'm sure there
are many more users with needs for at least one specialized group (with the end
result that _all_ specialized groups are needed).

You cannot design a program for everybody. If you do that, then it's suitable for nobody.

Post by Kevin Kofler
And another issue is that the library design doesn't allow making a more
powerful UI on top of the same library, because the "simple" groups are
hardcoded and there's no API to get to the actual groups.

You mean the DBUS API is not sufficient.

Post by Kevin Kofler
Even if we accept
your premise that a package manager for power users necessarily has to be a
different application, it would still be nice to be able to build it on the
same library. Reinventing the wheel to work around library limitations would be
a big waste. For example, KPackageKit could potentially be that "more powerful
UI" if the library allowed it.

kpackagekit uses it's own bindings and library. If you actually joined
the upstream mailing list, you can see we are discussing what to do,
perhaps adding another group API to compliment the "simple one".

But now I'm bored, it just seems like you are wasting my time. I listen
most to people that actually contribute code.

Sorry to be blunt.

Richard.

[Jesse Keating]

Post by Richard Hughes
I listen
most to people that actually contribute code.

This is not going to be helpful.

Which of http://www.packagekit.org/pk-profiles.html these people
contributed code to PackageKit?
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080923/183a4723/attachment.bin

[Nicolas Mailhot]

Post by Richard Hughes

Post by Kevin Kofler

Post by Richard Hughes
You think we NEED a "KDE Software Development group". PackageKit is not
designed for you. Can you explain how having fine grained groups would
help people like: http://www.packagekit.org/pk-profiles.html ?

Well, at least the med student could have a use for a "medical applications"
group (which I'm aware does not currently exist, but that's not PackageKit's
problem ;-) )

A simple collection (one package) would solve that need, rather than a
whole group of packages that she wouldn't know what any of them did.

Users like simple jumbo mono-package solutions, but they're not
maintenable in the real world (and are usually a licensing trap).

Comps complexity and number of packages/groups have not evolvded from a
wish to make users or comps writers life difficult, but from the need to
present lots of granular packages (engineering, maintainership and legal
requirement) to people with lots of different interests (many targetted
groups)

It's always easy to present one-shot specialized solutions. The
difficulty is scaling because separate maintenance of specialized
overlapping package collections is not efficient).

When you refuse to look at scaling problems you're missing the core of
the problem.
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080923/4408d798/attachment.bin

[Jeff Spaleta]

Post by Richard Hughes
You think we NEED a "KDE Software Development group". PackageKit is not
designed for you. Can you explain how having fine grained groups would
help people like: http://www.packagekit.org/pk-profiles.html ?
PackageKit is not designed for the sort of users who are comfortable
using yum on the command line. PackageKit doesn't replace yum, it's just
complimentary. If we designed PK as a "suitable for any user" tool then
it would be suitable for no-one. Hence the need for a profiles page.

Can the motivating profiles for PK be extended to include situations
where an instituttion is looking to create its own group definition
for inhouse software for specific desktop users tasking?

For example the medical school that your example medical student goes
to may very well want to give its linux users a centralized way to
access inhouse curriculum software utilities and may feel the best way
to do that is to provide a dedicated grouping in a comps file
definition in its local school package repository. Will PK grow to
help those institutional users? Are you asking institutions who are
running local, non-public, repositories to tell their medical student
analogs to drop to the cmdline to install the inhouse software
utilities via yum groupinstall, instead of exposing the institution's
groupings via PK UI?

The best part of comps to me, is the fact that local, non-public,
institutional repositories have the flexibility to define their own
groupings that best meet their situational needs.. without getting
stuck in the god forsaken debate over how a particular distribution
chooses to organize things. For academic institutions like medical
schools, that could end up looking like curriculum or courseware
groupings... grouping concepts we'd never ever need to consider in the
most general case. Can anyone say that's not a valid way to make use
of the flexiblity comps in an institutional setting? I can't.

-jef"We can probably spend the next several months doing nothing more
but nitpick how we group things in Fedora's comps. Or in fact
nitpicking how anyone defines a group. I'm sure historians who focus
on brick and mortar library catelog schemes will get a big kick out of
it."spaleta

[Matthias Clasen]

Post by Nicolas Mailhot

[...]
* throw out the hardcoded categories! We have that information in compsxml,
PackageKit should not try to duplicate it.

The PK argument used to be comps groups suck, are distro-specific, have
no equivalent on some distros, so people should drop comps and
contribute to pk hardcoded stuff instead.

Where did you get that idea ?

[Kevin Kofler]

Post by Matthias Clasen

Post by Nicolas Mailhot
The PK argument used to be comps groups suck, are distro-specific, have
no equivalent on some distros, so people should drop comps and
contribute to pk hardcoded stuff instead.

Where did you get that idea ?

Just read Richard Hughes's interventions in this thread.

Kevin Kofler

[Nicolas Mailhot]

Post by Matthias Clasen

Post by Nicolas Mailhot

[...]
* throw out the hardcoded categories! We have that information in compsxml,
PackageKit should not try to duplicate it.

The PK argument used to be comps groups suck, are distro-specific, have
no equivalent on some distros, so people should drop comps and
contribute to pk hardcoded stuff instead.

Where did you get that idea ?

Already had many exchanges with Richard on the subject :)
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080923/9ad8adb5/attachment.bin

[Arthur Pemberton]

Post by Nicolas Mailhot

Post by Matthias Clasen

Post by Nicolas Mailhot

[...]
* throw out the hardcoded categories! We have that information in compsxml,
PackageKit should not try to duplicate it.

The PK argument used to be comps groups suck, are distro-specific, have
no equivalent on some distros, so people should drop comps and
contribute to pk hardcoded stuff instead.

Where did you get that idea ?

Already had many exchanges with Richard on the subject :)

If this is the idea, then this needs to be done at the LSB level, and
let it filter down to the distros. Frankly, I thought the idea was to
fit into each distro, not override each distro

[Alex Lancaster]

Tim Lauridsen <tim.lauridsen <at> googlemail.com> writes: [...]
IMHO, a much better approach would be to: * throw out the hardcoded
categories! We have that information in comps.xml, PackageKit
should not try to duplicate it. * display the comps.xml groups
instead of the hardcoded categories and * add tristate checkboxes
next to the groups, like in Anaconda: by default, they're in the
gray state, unless you have all packages installed (checked) or
none (unchecked); they can be checked or unchecked, which is
equivalent to a groupinstall or groupremove, but the only way to
get them into the gray state is to individually install or remove
packages from the group (using the list view on the right).

TL> Strong +1 with one addition for us:

TL> * Fedora and its package maintainers need to way better job making
TL> sure that most if not all packages are properly listed in
TL> comps.xml -- otherwise a good portion of our packages won't show
TL> up in any of the groups

Ideally this would be done either as a mandatory part of the original
CVS import request (a field could be added, with an opt-out provision
if really not appropriate for comps), or added interactively by the
maintainer via PackageDB as I suggested in the feature request here:

https://fedorahosted.org/packagedb/ticket/78#comment:1

Having to manually update the comps.xml file for multiple releases is
painful, error-prone and probably why most package maintainers ignore
it, especially since it is not enforced in package reviews.

Alex

[Thorsten Leemhuis]

Post by Alex Lancaster

Tim Lauridsen <tim.lauridsen <at> googlemail.com> writes: [...]
IMHO, a much better approach would be to: * throw out the hardcoded
categories! We have that information in comps.xml, PackageKit
should not try to duplicate it. * display the comps.xml groups
instead of the hardcoded categories and * add tristate checkboxes
next to the groups, like in Anaconda: by default, they're in the
gray state, unless you have all packages installed (checked) or
none (unchecked); they can be checked or unchecked, which is
equivalent to a groupinstall or groupremove, but the only way to
get them into the gray state is to individually install or remove
packages from the group (using the list view on the right).

TL> * Fedora and its package maintainers need to way better job making
TL> sure that most if not all packages are properly listed in
TL> comps.xml -- otherwise a good portion of our packages won't show
TL> up in any of the groups
Ideally this would be done either as a mandatory part of the original
CVS import request (a field could be added, with an opt-out provision
if really not appropriate for comps), or added interactively by the
https://fedorahosted.org/packagedb/ticket/78#comment:1

Hmmmm. How much does the pkgdb know about the binary packages that get
build from the source packages? Not much afaics, as the pkgdb mainly
(only?) works with the (source) packages and not the ones that get build
from it -- but in a proper comps.xml we need to list the binary
packages, as a user might want to select the packages (rpms) foo or bar
that both might get build from the package (srpm) foobar.

Post by Alex Lancaster
Having to manually update the comps.xml file for multiple releases is
painful, error-prone and probably why most package maintainers ignore
it, especially since it is not enforced in package reviews.

+1

CU
knurd

[Toshio Kuratomi]

Post by Thorsten Leemhuis

Post by Alex Lancaster
Ideally this would be done either as a mandatory part of the original
CVS import request (a field could be added, with an opt-out provision
if really not appropriate for comps), or added interactively by the
https://fedorahosted.org/packagedb/ticket/78#comment:1

Hmmmm. How much does the pkgdb know about the binary packages that get
build from the source packages? Not much afaics, as the pkgdb mainly
(only?) works with the (source) packages and not the ones that get build
from it -- but in a proper comps.xml we need to list the binary
packages, as a user might want to select the packages (rpms) foo or bar
that both might get build from the package (srpm) foobar.

Post by Alex Lancaster
Having to manually update the comps.xml file for multiple releases is
painful, error-prone and probably why most package maintainers ignore
it, especially since it is not enforced in package reviews.

+1

So here's where I'm at WRT binary packages.

We have too many apps interested in doing only a subset of the work in
this area.

There's amber which is going to provide an end user view of applications
(rather than packages) with categories and tags. There's Fedora
collection which probably won't have a permanent data store of its own.
There's PackageDB which oculd be expanded to handle this (it has tables
for binary packages but is unfilled with data). There's koji which
touches every binary package, consumes and generates comps files.
There's comps.xml which is the master store for this information right
now. There's repoview which provides a static interface to binary
packages and comps on the gold repo but not yet updates -- if it is
updated to work on updates, that will require bodhi to write out the files.

So:

1) In which app should the canonical storage for this reside?
2) What interface do we want to put on top of the storage?
3) What apps will need to pull data from there once we have it?

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080922/bd308596/attachment.bin

[Kevin Fenzi]

On Mon, 22 Sep 2008 12:31:29 -0700

Post by Toshio Kuratomi

Post by Thorsten Leemhuis

Post by Alex Lancaster
Ideally this would be done either as a mandatory part of the
original CVS import request (a field could be added, with an
opt-out provision if really not appropriate for comps), or added
interactively by the maintainer via PackageDB as I suggested in
https://fedorahosted.org/packagedb/ticket/78#comment:1

Hmmmm. How much does the pkgdb know about the binary packages that
get build from the source packages? Not much afaics, as the pkgdb
mainly (only?) works with the (source) packages and not the ones
that get build from it -- but in a proper comps.xml we need to list
the binary packages, as a user might want to select the packages
(rpms) foo or bar that both might get build from the package (srpm)
foobar.

Post by Alex Lancaster
Having to manually update the comps.xml file for multiple releases
is painful, error-prone and probably why most package maintainers
ignore it, especially since it is not enforced in package reviews.

+1

Yeah, agreed here too.

Post by Toshio Kuratomi
So here's where I'm at WRT binary packages.
We have too many apps interested in doing only a subset of the work in
this area.
There's amber which is going to provide an end user view of
applications (rather than packages) with categories and tags.
There's Fedora collection which probably won't have a permanent data
store of its own. There's PackageDB which oculd be expanded to handle
this (it has tables for binary packages but is unfilled with data).
There's koji which touches every binary package, consumes and
generates comps files.

I thought it was mash that consumed and generated the comps files?

Post by Toshio Kuratomi
There's comps.xml which is the master store
for this information right now. There's repoview which provides a
static interface to binary packages and comps on the gold repo but
not yet updates -- if it is updated to work on updates, that will
require bodhi to write out the files.
1) In which app should the canonical storage for this reside?

Perhaps we could get together a meeting of koji, mash, bodhi, pkgdb
folks and hash this out?

Post by Toshio Kuratomi
2) What interface do we want to put on top of the storage?
3) What apps will need to pull data from there once we have it?

I think 2 and 3 will depend on where the data ends up being stored.

Post by Toshio Kuratomi
-Toshio

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080924/4f8731b3/attachment.bin

[Jesse Keating]

Post by Toshio Kuratomi
There's koji which
touches every binary package, consumes and generates comps files.
There's comps.xml which is the master store for this information right
now. There's repoview which provides a static interface to binary
packages and comps on the gold repo but not yet updates -- if it is
updated to work on updates, that will require bodhi to write out the files.

Kevin is right, it's mash that pulls comps out of cvs and 'makes' it and
uses it when generating repodata. Mash is used during rawhide
production and during update repo generation. When we make releases,
that uses pungi which consumes the comps data that mash generated and
merges in data from any other repo pungi is configured to use. Then
pungi calls repoview to create data based on that merged comps.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080924/672719e3/attachment.bin

[Richard Hughes]

Post by Kevin Kofler
As you'll certainly ask me why, i.e. what's wrong with the current
* there is no way to see what's in the collection,

You get prompted with the full list when you try and install. You can
use Get Dependencies on the collection if you want to know beforehand.

Post by Kevin Kofler
* it is inconsistent: both the comps.xml groups and the hardcoded categories
are lists of packages

The hardcoded groups are not lists of packages, it's a map of comps
groups to PK groups.

Post by Kevin Kofler
* throw out the hardcoded categories! We have that information in comps.xml,
PackageKit should not try to duplicate it.

It's not. Groups are a subset of the comps groups. I've done substantial
user research, and I'm sorry to say fine grained categories _do not
work_ with real users. None of the people in
http://www.packagekit.org/pk-profiles.html could tell me what they
expected to find in base-system/system-tools or base-system/admin-tools,
or tell me the difference between them.

Post by Kevin Kofler
* add tristate checkboxes next to the groups, like in Anaconda: by default,
they're in the gray state, unless you have all packages installed (checked) or
none (unchecked); they can be checked or unchecked, which is equivalent to a
groupinstall or groupremove, but the only way to get them into the gray state
is to individually install or remove packages from the group (using the list
view on the right).

That would be a usability disaster. Do you want to try explaining how a
tristate checkbox works to any of the people on the profiles page?

Richard.

[Jesse Keating]

Post by Richard Hughes
It's not. Groups are a subset of the comps groups. I've done substantial
user research, and I'm sorry to say fine grained categories _do not
work_ with real users. None of the people in
http://www.packagekit.org/pk-profiles.html could tell me what they
expected to find in base-system/system-tools or base-system/admin-tools,
or tell me the difference between them.

So your solution is to invent something else entirely, rather than
helping Fedora clean up its groupings definitions? Really? Nice.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080922/57a62c9e/attachment.bin

[Richard Hughes]

Post by Jesse Keating
So your solution is to invent something else entirely, rather than
helping Fedora clean up its groupings definitions? Really? Nice.

No. PK groups are made up _from_ the comps groups. There are just an
order of magnitude less options, and it's a flat list rather than a
tree. Comps supports optional, mandatory, suggested and the sort of
power user stuff that I just don't want to support in PackageKit.

For me to "clean up the groups" would be to rip out all optional groups,
rip out most of the obscure categories and add lots of packages with
lots of extra deps. I'm sure that's not what you want me to do with
comps at all.

If you want to actually help with this stuff, can I suggest you join the
PackageKit mailing list and discuss there? Fedora isn't the only
consumer of PackageKit, and I'm keen on working upstream on ideas and
policies with other distros rather than just defending decisions made
upstream that affect fedora.

And just correcting you: this wasn't _my_ decision, this was the result
of working with lots of other distros. Sarcasm doesn't help anybody.

Richard.

[Kevin Kofler]

Post by Richard Hughes
No. PK groups are made up _from_ the comps groups. There are just an
order of magnitude less options, and it's a flat list rather than a
tree. Comps supports optional, mandatory, suggested and the sort of
power user stuff that I just don't want to support in PackageKit.

So you want PackageKit to be useless for power users? Then what should power
users use?

Post by Richard Hughes
For me to "clean up the groups" would be to rip out all optional groups,
rip out most of the obscure categories and add lots of packages with
lots of extra deps. I'm sure that's not what you want me to do with
comps at all.

The optional groups all exist for a reason, they shouldn't be removed, but they
also shouldn't be hidden (which for an end user is essentially the same as
removing).

Post by Richard Hughes
If you want to actually help with this stuff, can I suggest you join the
PackageKit mailing list and discuss there? Fedora isn't the only
consumer of PackageKit, and I'm keen on working upstream on ideas and
policies with other distros rather than just defending decisions made
upstream that affect fedora.

Then (i.e. if there's disagreement between distributions on how to handle this)
there needs to be a way for a distribution to configure this, and the
configuration in Fedora should reflect Fedora's wishes, not those of other
distributions.

Kevin Kofler

[Arthur Pemberton]

Post by Richard Hughes

Post by Jesse Keating
So your solution is to invent something else entirely, rather than
helping Fedora clean up its groupings definitions? Really? Nice.

No. PK groups are made up _from_ the comps groups. There are just an
order of magnitude less options, and it's a flat list rather than a
tree. Comps supports optional, mandatory, suggested and the sort of
power user stuff that I just don't want to support in PackageKit.

You should have said this earlier. This puts this discussion in the
hands of UI and design specialists, as opposed to developers. Which
may mean that Fedora is the wrong place to do most of this work.
Because this suggests that this tool will be useless to me. I tried to
use packagekit when I first installed it. I was taking some notes to
file bugs, but these will likely not be of interest as they are aimed
more at users like myself.

There is no reason why an abstracted GUI should be less easy to use than yum.

[Jesse Keating]

Post by Richard Hughes
No. PK groups are made up _from_ the comps groups. There are just an
order of magnitude less options, and it's a flat list rather than a
tree. Comps supports optional, mandatory, suggested and the sort of
power user stuff that I just don't want to support in PackageKit.

Well that's just too damn bad. You're making things /worse/ by having a
different view of things post-install than you had during install. This
was one of the /best/ things about pirut is that you got the same
familiar UI, whether that UI was good or bad didn't matter, it was
the /same/ and /consistent/.

Post by Richard Hughes
For me to "clean up the groups" would be to rip out all optional groups,
rip out most of the obscure categories and add lots of packages with
lots of extra deps. I'm sure that's not what you want me to do with
comps at all.

Well it'd certainly be a starting point for a conversation, which is
much better than decisions being made about our distribution and what
our users see in our distribution discussed and made somewhere that
was /not/ our distribution. Hurting, not helping.

Post by Richard Hughes
If you want to actually help with this stuff, can I suggest you join the
PackageKit mailing list and discuss there? Fedora isn't the only
consumer of PackageKit, and I'm keen on working upstream on ideas and
policies with other distros rather than just defending decisions made
upstream that affect fedora.

If I'd known that upstream was actively looking to destroy our package
classifications, rather than actually work with us to clean them up a
bit maybe I would have joined the conversation. A heads up might have
been in order. I fear that any conversation now will just be too little
too late.

Post by Richard Hughes
And just correcting you: this wasn't _my_ decision, this was the result
of working with lots of other distros. Sarcasm doesn't help anybody.

Neither does letting other distributions make decisions about ours.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080922/746824d2/attachment.bin

[Matthias Clasen]

Post by Jesse Keating

Post by Richard Hughes
No. PK groups are made up _from_ the comps groups. There are just an
order of magnitude less options, and it's a flat list rather than a
tree. Comps supports optional, mandatory, suggested and the sort of
power user stuff that I just don't want to support in PackageKit.

Well that's just too damn bad. You're making things /worse/ by having a
different view of things post-install than you had during install. This
was one of the /best/ things about pirut is that you got the same
familiar UI, whether that UI was good or bad didn't matter, it was
the /same/ and /consistent/.

Post by Richard Hughes
For me to "clean up the groups" would be to rip out all optional groups,
rip out most of the obscure categories and add lots of packages with
lots of extra deps. I'm sure that's not what you want me to do with
comps at all.

Well it'd certainly be a starting point for a conversation, which is
much better than decisions being made about our distribution and what
our users see in our distribution discussed and made somewhere that
was /not/ our distribution. Hurting, not helping.

Post by Richard Hughes
If you want to actually help with this stuff, can I suggest you join the
PackageKit mailing list and discuss there? Fedora isn't the only
consumer of PackageKit, and I'm keen on working upstream on ideas and
policies with other distros rather than just defending decisions made
upstream that affect fedora.

If I'd known that upstream was actively looking to destroy our package
classifications, rather than actually work with us to clean them up a
bit maybe I would have joined the conversation. A heads up might have
been in order. I fear that any conversation now will just be too little
too late.

Post by Richard Hughes
And just correcting you: this wasn't _my_ decision, this was the result
of working with lots of other distros. Sarcasm doesn't help anybody.

Neither does letting other distributions make decisions about ours.

Thanks Jesse, for making it clear that you are more interested in
confrontation than a constructive discussion impossible.

People who are interested in improving PackageKit should probably take
the discussion to the packagekit list (packagekit at lists.freedesktop.org)

[Jesse Keating]

Post by Matthias Clasen
Thanks Jesse, for making it clear that you are more interested in
confrontation than a constructive discussion impossible.

I'm interested in fixing our comps files, since that's what is used by
our installer, our compose tools, our package tools such as yum, our
developers, our documentation, etc, etc...

I won't argue that it could use improvement. I will however argue that
the way to improve it is to have dialog with those using it and
producing it, rather than deciding off project somewhere to just ignore
it or apply filtering/modification to it without consulting the project
at all.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080922/a5893d6c/attachment.bin

[Kevin Kofler]

This post might be inappropriate. Click to display it.

[Nicolas Mailhot]

Post by Matthias Clasen

Post by Jesse Keating

Post by Richard Hughes
And just correcting you: this wasn't _my_ decision, this was the result
of working with lots of other distros. Sarcasm doesn't help anybody.

Neither does letting other distributions make decisions about ours.

Thanks Jesse, for making it clear that you are more interested in
confrontation than a constructive discussion impossible.

Constructive discussion needs to be 2 way. I had to write down the PK
position on this for people on fedora-devel to learn what decisions were
being made for them. And the decisions touched packaging which is
fedora-devel main subject. (unfortunately the desktop team mislike for
the common distro communication channel is not new).

I sure hope the "other distro representatives" we've read so much on
were more representative than the Fedora ones.

Post by Matthias Clasen
People who are interested in improving PackageKit should probably take
the discussion to the packagekit list (packagekit at lists.freedesktop.org)

But we're not interested in improving PK. We're interested in improving
Fedora. If PK intends to focus on a non-Fedora user, we're not
interested in PK are we?
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080923/f6eb9589/attachment.bin

[Richard Hughes]

Post by Nicolas Mailhot
But we're not interested in improving PK. We're interested in
improving Fedora. If PK intends to focus on a non-Fedora user, we're
not interested in PK are we?

I don't respond to silly threats, sorry.

Richard.

[Nicolas Mailhot]

Post by Nicolas Mailhot

Post by Matthias Clasen
Thanks Jesse, for making it clear that you are more interested in
confrontation than a constructive discussion impossible.

Constructive discussion needs to be 2 way.

Sorry, got carried over. I apologise for the abrasiveness.

Still, any decision concerning the way we install or update the distro
is releng territory IMHO, and I'm distressed that Jesse didn't seem to
be in the loop at all.

(I could live with PK people disagreeing with me. That's ok, I
disagree with lots of people)

[Richard Hughes]

Post by Nicolas Mailhot
Sorry, got carried over. I apologise for the abrasiveness.

Cool, thanks.

Post by Nicolas Mailhot
Still, any decision concerning the way we install or update the distro
is releng territory IMHO, and I'm distressed that Jesse didn't seem to
be in the loop at all.

Sure, possibly my fault too -- I always ask people to join the mailing
list and jump in on pretty much any discussion -- but maybe I need to
actively _invite_ more people.

Post by Nicolas Mailhot
(I could live with PK people disagreeing with me. That's ok, I
disagree with lots of people)

Disagreement is good. People get angry because they care about the
outcome, and that's a totally positive thing.

Richard.

[Kevin Kofler]

Post by Richard Hughes
That would be a usability disaster. Do you want to try explaining how a
tristate checkbox works to any of the people on the profiles page?

How else do you want to represent a group? A group can be partially installed,
you can't just show it as not installed (then how do you represent uninstalling
it?) or installed (then how do you represent installing it completely?),
showing a group as not installed or as installed when it's actually partially
installed is going to confuse users.

Tristate checkboxes are a very common UI to represent groups where a more
detailed selection is available, many Window$ installers use them (and those
are surely targeted at the average user!), as does Anaconda (or at least used
to do). A tristate in the gray state is a clear hint that you have to go to the
details to see what exactly is selected and unselected.

Kevin Kofler

[Richard Hughes]

Post by Kevin Kofler
Tristate checkboxes are a very common UI to represent groups where a more
detailed selection is available, many Window$ installers use them (and those
are surely targeted at the average user!), as does Anaconda (or at least used
to do). A tristate in the gray state is a clear hint that you have to go to the
details to see what exactly is selected and unselected.

I've done two user-screencasts of people navigating groups using pirut
who have never used pirut or PackageKit before. I can upload them
somewhere if poeple are interested, although they are pretty big.

Tri-state checkboxes are a disaster.

Richard.

[Michael Schroeder]

Post by Richard Hughes

Post by Kevin Kofler
Tristate checkboxes are a very common UI to represent groups where a more
detailed selection is available, many Window$ installers use them (and those
are surely targeted at the average user!), as does Anaconda (or at least used
to do). A tristate in the gray state is a clear hint that you have to go to the
details to see what exactly is selected and unselected.

I've done two user-screencasts of people navigating groups using pirut
who have never used pirut or PackageKit before. I can upload them
somewhere if poeple are interested, although they are pretty big.

I'm interested, could you please make them available?

Thanks,
Michael.

[Richard Hughes]

Post by Michael Schroeder
I'm interested, could you please make them available?

Sure, I'll ask kenvandine if I can use packagekit.org (it's a VM in a
colo) as I'm betting he's not keen on several people downloading 200Mb+
at at the same time.

I've got a 147M quota on rhughes.fedoraproject.org -- is there anyway I
can get this bumped up to ~300Mb?

Richard.

[seth vidal]

Post by Richard Hughes

Post by Michael Schroeder
I'm interested, could you please make them available?

Sure, I'll ask kenvandine if I can use packagekit.org (it's a VM in a
colo) as I'm betting he's not keen on several people downloading 200Mb+
at at the same time.
I've got a 147M quota on rhughes.fedoraproject.org -- is there anyway I
can get this bumped up to ~300Mb?

it's rhughes.fedorapeople.org

and your quota is now raised to 400M

-sv

[Richard Hughes]

Post by seth vidal
it's rhughes.fedorapeople.org
and your quota is now raised to 400M

Legend, thanks. I'll upload this afternoon.

Richard

[Michael Schroeder]

Post by Richard Hughes

Post by seth vidal
it's rhughes.fedorapeople.org
and your quota is now raised to 400M

Legend, thanks. I'll upload this afternoon.

Any progress on the upload?

Thanks,
Michael.

[James Antill]

Post by Tim Lauridsen
The groups in comps.xml is used as meta-packages, there can be installed
and removed. just like yum groupinstall/groupremove.

But that's not how groupinstall/groupremove works! Groups are _very_
different from meta-packages, for instance:

yum shell <<EOL
install @x-software-development
remove libXaw-devel
run
EOL

...at the end of this the 'X Software Development' group is not
installed.
Why doesn't PK make it's "categories" the same as the yum backends
"groups"? I can't even see how to install the above group in PK.

But then 0.3.2 is still doing utterly broken direct SQL calls, and
failing *sigh*.
--
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080922/33734147/attachment.bin

[Richard Hughes]

Post by James Antill
But then 0.3.2 is still doing utterly broken direct SQL calls, and
failing *sigh*.

Yes, that was ripped out when the fixed yum was pushed to F9.

Richard.

[Tim Lauridsen]

Post by James Antill

Post by Tim Lauridsen
The groups in comps.xml is used as meta-packages, there can be installed
and removed. just like yum groupinstall/groupremove.

But that's not how groupinstall/groupremove works! Groups are _very_
yum shell <<EOL
remove libXaw-devel
run
EOL

in the pk yum backend a "meta package" the same as a yum group.

InstallPackages('x-software-development;meta;meta;meta')

will do the same as 'yum install @x-software-development"

but on other package managers it can be something else.

Post by James Antill
But then 0.3.2 is still doing utterly broken direct SQL calls, and
failing *sigh*.

it is fixed in 0.3.3

Tim

[Kevin Kofler]

Post by James Antill
But that's not how groupinstall/groupremove works! Groups are _very_
yum shell <<EOL
remove libXaw-devel
run
EOL
...at the end of this the 'X Software Development' group is not
installed.

... and that's exactly why tristates are needed.

Post by James Antill
Why doesn't PK make it's "categories" the same as the yum backends
"groups"?

+1, that's what most of us are asking.

Kevin Kofler

[James Antill]

Post by Kevin Kofler

Post by James Antill
But that's not how groupinstall/groupremove works! Groups are _very_
yum shell <<EOL
remove libXaw-devel
run
EOL
...at the end of this the 'X Software Development' group is not
installed.

.. and that's exactly why tristates are needed.

You want installed: yes/no/maybe?

IMNSHO it'd be _much_ better to just treat groups as collections of
packages (in the UI) instead of trying to convince the user they are
real objects they can manipulate in some way.

[Kevin Kofler]

Post by James Antill

Post by Kevin Kofler
.. and that's exactly why tristates are needed.

You want installed: yes/no/maybe?

Yes/no/partially.
A group for which some, but not all packages are installed is "partially
installed" and would be represented by the tristate's "intermediate" state (the
one with the gray checkmark).
This is a very common idiom in software installers.

Kevin Kofler

[Dennis Gilmore]

Post by Thorsten Leemhuis
Hi all!
I recently created comps.xml files for RPM Fusion. During that a few
things around comps.xml got discussed on the RPM Fusion lists(?).
That and a recent change (?) to
https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
How important is comps.xml to us these days?
(Note that I mean Fedora and RPM Fusion with "us" here, as RPM Fusion
for things like this just follows the Fedora guidelines)
Comps.xml is afaics mainly used in anaconda (and thus indirectly in
tools like pungi that rely on anaconda) and yum (if you know what to do)
these days; PackageKit afaics doesn't use it much (or does it use
comps.xml at all? Will that change?); it just lists everything it finds
afaics (correct me if I'm wrong, I'm not using PackageKit much and just
use yum directly).

comps.xml is used by yum when doing group functions also so "yum
groupinstall xfce-desktop" gets that group info from the comps file. its
still pretty vital. and to get the highest visability to your package you
should be entering it.

Dennis

[Thorsten Leemhuis]

Post by Dennis Gilmore

Post by Thorsten Leemhuis
I recently created comps.xml files for RPM Fusion. During that a few
things around comps.xml got discussed on the RPM Fusion lists(?).
That and a recent change (?) to
https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
How important is comps.xml to us these days?
(Note that I mean Fedora and RPM Fusion with "us" here, as RPM Fusion
for things like this just follows the Fedora guidelines)
Comps.xml is afaics mainly used in anaconda (and thus indirectly in
tools like pungi that rely on anaconda) and yum (if you know what to do)
these days; PackageKit afaics doesn't use it much (or does it use
comps.xml at all? Will that change?); it just lists everything it finds
afaics (correct me if I'm wrong, I'm not using PackageKit much and just
use yum directly).

Seems you didn't get what I was up to. Sorry, my fault. Let me try again.

Post by Dennis Gilmore
comps.xml is used by yum when doing group functions also so "yum
groupinstall xfce-desktop" gets that group info from the comps file.

Sure.

Post by Dennis Gilmore
its still pretty vital.

Sure. But it afaics could be a whole lot more "vital" if all packagers
would use it and would use it in the same way.

Post by Dennis Gilmore
and to get the highest visability to your package you
should be entering it.

Sure. But if you read my mail up to the end you will notice that a good
bunch of packagers don't care and don't add their packages to comps. I
want to know if we in Fedora (the project/the distribution) should work
towards fixing that. That implies a proper policy (which is not really
clear right now), fixing the current mess where round about one/third of
our packages (or even more; depends on the way you count) are missing in
comps.xml and making sure all apps present the data from comps in a
similar way.

Cu
knurd

[Alex Lancaster]

[...]

and to get the highest visability to your package you should be
entering it.

TL> Sure. But if you read my mail up to the end you will notice that a
TL> good bunch of packagers don't care and don't add their packages to
TL> comps. I want to know if we in Fedora (the project/the
TL> distribution) should work towards fixing that. That implies a
TL> proper policy (which is not really clear right now), fixing the
TL> current mess where round about one/third of our packages (or even
TL> more; depends on the way you count) are missing in comps.xml and
TL> making sure all apps present the data from comps in a similar way.

Yep, this is a real problem with the comps.xml approach at the moment.
See the feature request:

https://fedorahosted.org/packagedb/ticket/78

and my response to another part of the thread.

Alex