Hi Bill,
can't we name our release s.th. like -0.x for xmms, so that users can use up2date and install the original xmms-xxx-1 from www.xmms.org with MP3 support?
On Tue, 2003-09-30 at 12:55, Harald Hoyer wrote:
can't we name our release s.th. like -0.x for xmms, so that users can use up2date and install the original xmms-xxx-1 from www.xmms.org with MP3 support?
I don't think this is necessary, as people easily can install xmms-mp3 packages from third parties on top of the Fedora xmms package.
Nils
Nils Philippsen (nphilipp@redhat.com) said:
can't we name our release s.th. like -0.x for xmms, so that users can use up2date and install the original xmms-xxx-1 from www.xmms.org with MP3 support?
I don't think this is necessary, as people easily can install xmms-mp3 packages from third parties on top of the Fedora xmms package.
That was my initial reaction... do more people install xmms-mp3, or the xmms.org packages?
Bill
On Tue, 2003-09-30 at 05:14, Bill Nottingham wrote:
Nils Philippsen (nphilipp@redhat.com) said:
can't we name our release s.th. like -0.x for xmms, so that users can use up2date and install the original xmms-xxx-1 from www.xmms.org with MP3 support?
I don't think this is necessary, as people easily can install xmms-mp3 packages from third parties on top of the Fedora xmms package.
That was my initial reaction... do more people install xmms-mp3, or the xmms.org packages?
Bill
I believe end users who don't know about apt/yum and third party repositories tend to download the full RPMS from xmms.org, while repository users tend to install xmms-mp3.
Warren
I believe end users who don't know about apt/yum and third party repositories tend to download the full RPMS from xmms.org, while repository users tend to install xmms-mp3.
I've been giving some thought to what to do about the possible glut of packages that could be in fedora extras/alternatives/etc
The problem is the same problem with the menus under X for a while - no one knew what 'xmms' was so they didn't know to look for it to play mp3s or oggs.
no one knew what galeon was so they didn't know to use it for web browsing, or epiphany or hell, mozilla, for that matter.
As an idea, once package submission starts happening into fedora extras it might be worthwhile to include some keywords describing the package or maybe make it a policy that packages include, in the description field a Keywords: foo bar baz line.
or maybe consider building up comps.xml/yumgroups.xml files that could create groups of packages for people to search for.
-sv
On Tue, 2003-09-30 at 22:36, seth vidal wrote:
or maybe consider building up comps.xml/yumgroups.xml files that could create groups of packages for people to search for.
That's what I'd like to see. Maybe even a requirement that all "end user visible" packages be in a comps file.
redhat-config-packages can then display nice sane things instead of raw RPM package names.
Havoc
On Tue, 2003-09-30 at 22:52, Havoc Pennington wrote:
On Tue, 2003-09-30 at 22:36, seth vidal wrote:
or maybe consider building up comps.xml/yumgroups.xml files that could create groups of packages for people to search for.
That's what I'd like to see. Maybe even a requirement that all "end user visible" packages be in a comps file.
redhat-config-packages can then display nice sane things instead of raw RPM package names.
I'm all for it - I wrote a simple script for generating a <group> section for a comps.xml file - they are intended for use with yum but since yumgroups.xml and comps.xml are the same file format (well, for the groups part, the packages part isn't really considered in yum - but it quietly ignores them so it's the same format :) then it would work just as well for those.
http://linux.duke.edu/projects/yum/download/misc/yumgengroups.py
If anyone is interested in it.
-sv
Havoc Pennington (hp@redhat.com) said:
On Tue, 2003-09-30 at 22:36, seth vidal wrote:
or maybe consider building up comps.xml/yumgroups.xml files that could create groups of packages for people to search for.
That's what I'd like to see. Maybe even a requirement that all "end user visible" packages be in a comps file.
redhat-config-packages can then display nice sane things instead of raw RPM package names.
redhat-config-packages already displays the description, which is already translated, etc....
Bill
On Tue, 2003-09-30 at 23:05, Bill Nottingham wrote:
Havoc Pennington (hp@redhat.com) said:
On Tue, 2003-09-30 at 22:36, seth vidal wrote:
or maybe consider building up comps.xml/yumgroups.xml files that could create groups of packages for people to search for.
That's what I'd like to see. Maybe even a requirement that all "end user visible" packages be in a comps file.
redhat-config-packages can then display nice sane things instead of raw RPM package names.
redhat-config-packages already displays the description, which is already translated, etc....
Well I think he meant it display groups of packages to be displayed as
"multimedia applications"
or
"sound and video"
instead of 'xmms' or 'totem' or 'xine'.
-sv
seth vidal (skvidal@phy.duke.edu) said:
Well I think he meant it display groups of packages to be displayed as
"multimedia applications"
or
"sound and video"
instead of 'xmms' or 'totem' or 'xine'.
Huh? You still need to *select* packagees, and they're already in a Sound and Video group.
Bill
Huh? You still need to *select* packagees, and they're already in a Sound and Video group.
But for stuff outside of the core distro - it would be useful to have them in comps.xml files on the other repositories so you could have those type of groups for the non-core packages too.
So if core has:
xmms noatun
in a multimedia group
then extras might have: xine (no illegal bindings) xmms-alsa totem
As it is r-c-p would need a comps.xml on the other repository for the package to be in a listed group.
when I wrote the comps.xml handling for yum I wrote a class that will take one or more comps.xml files and merge the groups b/t them.
So if repo1 had a comps with a group named 'sound and video' that included xmms and noatun and repo2 had a group named 'sound and video' that included xmms-alsa, totem and xine, then when you view the contents of the group from w/i yum you ended up with a group named 'sound and video' that included: xine, xmms, xmms-alsa, totel and noatun.
I think what havoc was meaning that programs that are going to be exposed to the user in the extras/alternatives/etc repositories should be listed in a comps.xml file and ideally then r-c-p could handle that part and list them nicely in those groups for the user.
-sv
seth vidal (skvidal@phy.duke.edu) said:
I think what havoc was meaning that programs that are going to be exposed to the user in the extras/alternatives/etc repositories should be listed in a comps.xml file and ideally then r-c-p could handle that part and list them nicely in those groups for the user.
Sure, but this is not necessarily meta-information in the package itself. Unless you just want to create rpm groups all over again.
Bill
On Tue, 2003-09-30 at 23:36, Bill Nottingham wrote:
seth vidal (skvidal@phy.duke.edu) said:
I think what havoc was meaning that programs that are going to be exposed to the user in the extras/alternatives/etc repositories should be listed in a comps.xml file and ideally then r-c-p could handle that part and list them nicely in those groups for the user.
Sure, but this is not necessarily meta-information in the package itself. Unless you just want to create rpm groups all over again.
I wasn't talking about meta-information in the package, I don't think havoc was either.
And afaict the rpm groups weren't too widely used.
-sv
Havoc Pennington said:
On Tue, 2003-09-30 at 22:36, seth vidal wrote:
or maybe consider building up comps.xml/yumgroups.xml files that could create groups of packages for people to search for.
That's what I'd like to see. Maybe even a requirement that all "end user visible" packages be in a comps file.
What relation (if any) does /usr/share/doc/rpm-<version>/GROUPS have here? Is this maintained seperately, being part of the rpm package instead of comps?
-Dan Young -Parkrose School District
On Tue, 2003-09-30 at 23:27, Dan Young wrote:
Havoc Pennington said:
On Tue, 2003-09-30 at 22:36, seth vidal wrote:
or maybe consider building up comps.xml/yumgroups.xml files that could create groups of packages for people to search for.
That's what I'd like to see. Maybe even a requirement that all "end user visible" packages be in a comps file.
What relation (if any) does /usr/share/doc/rpm-<version>/GROUPS have here? Is this maintained seperately, being part of the rpm package instead of comps?
I believe the only thing that really uses those groups anymore is rpmlint.
They have almost no meaning and there isn't enough depth or breadth to let them be a good classifier, imo.
-sv
Quoting seth vidal skvidal@phy.duke.edu:
On Tue, 2003-09-30 at 23:27, Dan Young wrote:
Havoc Pennington said:
On Tue, 2003-09-30 at 22:36, seth vidal wrote:
or maybe consider building up comps.xml/yumgroups.xml files that could create groups of packages for people to search for.
That's what I'd like to see. Maybe even a requirement that all "end user visible" packages be in a comps file.
What relation (if any) does /usr/share/doc/rpm-<version>/GROUPS have here? Is this maintained seperately, being part of the rpm package instead of comps?
I believe the only thing that really uses those groups anymore is rpmlint.
Synaptic uses (rpm) groups to organize the package tree view - typos in rpm groups show up really nicely there :) Things like
Application/Multimedia + somedvdplayer Applications/Multimedia + multimediaplayer1 + multimediaplayer2 + ..etc
They have almost no meaning and there isn't enough depth or breadth to let them be a good classifier, imo.
Yup, many packages don't have a real match in the "official" rpm group list at all and others could be put into one of several groups, typically things like python modules: is this System Environment/Libraries, Development/Libraries or Development/Languages .. when it fits to all of those.
Synaptic uses (rpm) groups to organize the package tree view - typos in rpm groups show up really nicely there :) Things like
Application/Multimedia + somedvdplayer Applications/Multimedia + multimediaplayer1 + multimediaplayer2 + ..etc
yah - the groups are fairly static wrt what rpmlint believes are 'correct' groups.
Yup, many packages don't have a real match in the "official" rpm group list at all and others could be put into one of several groups, typically things like python modules: is this System Environment/Libraries, Development/Libraries or Development/Languages .. when it fits to all of those.
That's one of the reasons why I thought keywords would be handy (in my original post)
-sv
Quoting seth vidal skvidal@phy.duke.edu:
Synaptic uses (rpm) groups to organize the package tree view - typos in
rpm
groups show up really nicely there :) Things like
Application/Multimedia + somedvdplayer Applications/Multimedia + multimediaplayer1 + multimediaplayer2 + ..etc
yah - the groups are fairly static wrt what rpmlint believes are 'correct' groups.
..except what rpmlint thinks are "correct" groups is miles longer a list than what's in GROUPS as distributed with rpm.
Yup, many packages don't have a real match in the "official" rpm group list
at
all and others could be put into one of several groups, typically things
like
python modules: is this System Environment/Libraries, Development/Libraries
or
Development/Languages .. when it fits to all of those.
That's one of the reasons why I thought keywords would be handy (in my original post)
Yup and I wholeheartedly agree keywords would be really nice.
On Wed, 2003-10-01 at 16:06, Panu Matilainen wrote:
Quoting seth vidal skvidal@phy.duke.edu:
Synaptic uses (rpm) groups to organize the package tree view - typos in
rpm
groups show up really nicely there :) Things like
Application/Multimedia + somedvdplayer Applications/Multimedia + multimediaplayer1 + multimediaplayer2 + ..etc
yah - the groups are fairly static wrt what rpmlint believes are 'correct' groups.
..except what rpmlint thinks are "correct" groups is miles longer a list than what's in GROUPS as distributed with rpm.
rpmlint thinks what you tell it to think in the config file :) For example, the default config in the fedora.us rpmlint package contains only the groups in /usr/share/doc/rpm-*/GROUPS, while the configuration we use in JPackage has the freshmeat.net categories.
The vanilla upstream configuration as well as some other parts in rpmlint is in many regards Mandrake-specific, and should be tweaked according to what one considers "correct".
On Tue, 30 Sep 2003, Dan Young wrote:
What relation (if any) does /usr/share/doc/rpm-<version>/GROUPS have here? Is this maintained seperately, being part of the rpm package instead of comps?
The GROUPS file provides a (not terribly well-defined) set of broad categories for packages. A GROUP tends to define what a package does (it's a library, daemon, application, documentation), though in some cases it defines a relationship (it's part of the Base system).
The comps.xml file provides package groupings for installation tools. The comps file combines packages of differing GROUPS into a useful installation category. For example, the Red Hat 9 "Printing Support" comps group includes packages from all sorts of GROUPS:
4Suite: Development/Libraries a2ps: Applications/Publishing cups: System Environment/Daemons enscript: Applications/Publishing ghostscript: Applications/Publishing hpijs: Applications/Publishing ttfprint: System Environment/Base redhat-config-printer: System Environment/Daemons ...
The newer comps.xml mechanism also has a way to specify installation-time dependencies.
--Paul Heinlein heinlein@madboa.com
On Tue, 30 Sep 2003, Bill Nottingham wrote:
Nils Philippsen (nphilipp@redhat.com) said:
can't we name our release s.th. like -0.x for xmms, so that users can use up2date and install the original xmms-xxx-1 from www.xmms.org with MP3 support?
I don't think this is necessary, as people easily can install xmms-mp3 packages from third parties on top of the Fedora xmms package.
That was my initial reaction... do more people install xmms-mp3, or the xmms.org packages?
The problem for the past few days was that there were no xmms-mp3-1.2.8 around, all were for 1.2.7, but there was an xmms-1.2.8 on xmms.org.
Bill
On Wed, 1 Oct 2003, seth vidal wrote:
The problem for the past few days was that there were no xmms-mp3-1.2.8 around, all were for 1.2.7, but there was an xmms-1.2.8 on xmms.org.
there has been one on rpm.livna.org
Thanks a lot for the link Seth. I was looking around for this place, but for I don't know what reason, I thought that noone's gonna shout it on the list.
this is, unofficially of course, where all the not-quite-so-legal fedora.us rpms have gone to.
-sv
Well, browse www.xmms.org and search for xmms-mp3 .. haven't found it in the download section.
Am Di, 2003-09-30 um 15.37 schrieb Nils Philippsen:
On Tue, 2003-09-30 at 12:55, Harald Hoyer wrote:
can't we name our release s.th. like -0.x for xmms, so that users can use up2date and install the original xmms-xxx-1 from www.xmms.org with MP3 support?
I don't think this is necessary, as people easily can install xmms-mp3 packages from third parties on top of the Fedora xmms package.
Nils
I noticed there's currently no video player available in fedora. I was wondering if i could make packages for xine or mplayer, but since these packages have a shitload of optional dependencies, i'd like to know what is the policy for 'hard' and 'soft' dependencies in packages. Also, do these programs bring licensing issues? (iirc mplayer and xine use win32 video codecs for DivX/etc decompression).
Thanks
On Fri, 2003-10-03 at 04:29, axel c wrote:
Also, do these programs bring licensing issues?
Do they ever. I don't think you can play many of the interesting video formats without issues. (See one of the dozens of HUGE threads on this list, and many other Red Hat lists, in the past. And no we can't include the stuff with licensing issues and this will not change, again, see those threads.)
For video player in Core, I'd like to see one of the toolkit-based players (either GTK+ or Qt). See http://fedora.redhat.com/projects/desktop/defaults.html
The general approach should be to have a player that uses a generic media framework such as gstreamer; and then third parties can add plugins. A player that has to link to plugins directly or via non-generic interfaces will not permit third party plugins.
Havoc
On Fri, 2003-10-03 at 17:11, Havoc Pennington wrote:
On Fri, 2003-10-03 at 04:29, axel c wrote:
Also, do these programs bring licensing issues?
Do they ever. I don't think you can play many of the interesting video formats without issues. (See one of the dozens of HUGE threads on this list, and many other Red Hat lists, in the past. And no we can't include the stuff with licensing issues and this will not change, again, see those threads.)
For video player in Core, I'd like to see one of the toolkit-based players (either GTK+ or Qt). See http://fedora.redhat.com/projects/desktop/defaults.html
The general approach should be to have a player that uses a generic media framework such as gstreamer; and then third parties can add plugins. A player that has to link to plugins directly or via non-generic interfaces will not permit third party plugins.
From the legal point of view, would it be possible to have gstreamer
automatically download missing plugins (even non-free/patented ones) ? That would of course mean that Fedora would have to have a list of repositories possibly containing packages with legal issues, even if none of those packages would be installed by default.
Note that I don't care, for the moment, whether it's _technically_ possible or not.
Havoc
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
Julien Olivier (julo@altern.org) said:
From the legal point of view, would it be possible to have gstreamer automatically download missing plugins (even non-free/patented ones) ? That would of course mean that Fedora would have to have a list of repositories possibly containing packages with legal issues, even if none of those packages would be installed by default.
No.
Bill
-
axel c -
Behdad Esfahbod -
Bill Nottingham -
Dan Young -
Harald Hoyer -
Havoc Pennington -
Julien Olivier -
Nils Philippsen -
Panu Matilainen -
Paul Heinlein -
seth vidal -
Ville Skyttä -
Warren Togami