IMHO the whole affected games should move to RPM Fusion Nonfree and autodownloader should be removed from Fedora. I really don't see why we're bypassing Fedora's licensing policies in this broken way when we could just offer a package that works out of the box in RPM Fusion Nonfree where it belongs.

On 05/16/2010 06:10 PM, Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 16 May 2010 at 02:02, Kevin Kofler wrote: > [...] > >> IMHO the whole affected games should move to RPM Fusion Nonfree and >> autodownloader should be removed from Fedora. >> >> I really don't see why we're bypassing Fedora's licensing policies in this >> broken way when we could just offer a package that works out of the box in >> RPM Fusion Nonfree where it belongs. >> > +1. If there's free game data available in the future, the game can be always > moved back to Fedora. > I am in agreement as well. The autodownloader model provides perhaps more exposure to the games but at the cost of every user having to download the same data repeatedly.

While I agree the the sentiment, the problem is that the maintainers of these games would have to agree to drop them in Fedora and then either package them themselves in RPM Fusion or allow others to package them. I'm not sure we'll get the necessary buy-in from them.

IMHO the whole affected games should move to RPM Fusion Nonfree and autodownloader should be removed from Fedora. I really don't see why we're bypassing Fedora's licensing policies in this broken way when we could just offer a package that works out of the box in RPM Fusion Nonfree where it belongs. Kevin Kofler +1 to move nonfree gamedata and affected game to rpmfusion. If

I've noticed a number of games whose content is distributable as long as it's distributed for free. A few of those games have ended up in Fedora but use autodownloader to download the game data. I really don't like this method because, at least as I understand it, the game data ends up in the user's home directory. If another user wants to play the game, they have to redownload the data. What is the feasibility of providing -data packages in rpmfusion-nonfree that would provide the data for said games, so the data could be installed system-wide? [...]

Hi, Jonathan Dieter wrote: > I've noticed a number of games whose content is distributable as long as > it's distributed for free. A few of those games have ended up in Fedora > but use autodownloader to download the game data. > > I really don't like this method because, at least as I understand it, > the game data ends up in the user's home directory. If another user > wants to play the game, they have to redownload the data. > > What is the feasibility of providing -data packages in rpmfusion-nonfree > that would provide the data for said games, so the data could be > installed system-wide? Can autodownloader (cc'ing autodownloader > maintainer) check for game data availability before downloading the data > off the internet? Well all autodownloader using games use a .sh script to launch autodownloader when the data is not present in the expected location, modifying those scripts to check for game-data under say /usr/share/%{name} first should not be a problem. Patches for that (together with rpmfusion packages of the data, so that the whole can be tested together) would definitely be welcome. I'm also always open to co-maintainers for the Fedora packages in question.

Do I understand this correctly? * FESCO has a approved an installer which circumvents rpm? * This installer is installing to /usr/share?

On 05/17/2010 02:39 PM, Rahul Sundaram wrote: > On 05/17/2010 06:03 PM, Ralf Corsepius wrote: > >> Do I understand this correctly? >> * FESCO has a approved an installer which circumvents rpm? >> >> * This installer is installing to /usr/share? >> > That seems to be a misunderstanding. Autodownloader downloads data to > your home directory. OK, it opens up the gates to worms and viruses.

> downloads and verifies them. > Can you explain how? Autodownloader has a hash of the files that it $HOME == automated arbitrary access to arbitrary user data == arbirary option to install maliculous programs (viruses, spyware etc.).

> Did you even try out autodownloader > and understand how it works? Doesn't seem like it at all. No, I haven't, and I certainly will not try it.

My point is a bit different: I consider this mechanism to be a way to *circumvent* rpm as means of packaging and it to be a way of encourage *sloppyness*, *lazyness* and *carelessness*, which endangers Fedora's users. If FESCO has a little understanding, they would have noticed that "mechanically packaging" game data into rpms and to ship them via repos is trivial. There is no need to add another mechanism for shipping packages and to endanger users from the security risks this comes attached with. Or differently: One fundamental key of rpm-based distros safety and consistency has been not to allowing other means of installation.

On 05/17/2010 04:34 PM, Jonathan Dieter wrote: > On Mon, 2010-05-17 at 15:36 +0200, Ralf Corsepius wrote: >> My point is a bit different: I consider this mechanism to be a way to >> *circumvent* rpm as means of packaging and it to be a way of encourage >> *sloppyness*, *lazyness* and *carelessness*, which endangers Fedora's users. >> >> If FESCO has a little understanding, they would have noticed that >> "mechanically packaging" game data into rpms and to ship them via repos >> is trivial. There is no need to add another mechanism for shipping >> packages and to endanger users from the security risks this comes >> attached with. >> >> Or differently: One fundamental key of rpm-based distros safety and >> consistency has been not to allowing other means of installation. > > Ralf, I think we all agree with the fact that it is optimal to install > game data as an rpm. The problem is that, for any game that uses > autodownloader, the data *cannot* be packaged in Fedora because of > license reasons. Rpmfusion can easily package them. RH or Fedora are not required to be involved into this at all.

I have to vehemently disagree. What RH has done with the firmware is having betrayed the OSS community, by claiming "Firmware is not SW". Though it has improved the uneducated user's "experience" this was a slap into the face of OSS-developers.

Ralf, I think we all agree with the fact that it is optimal to install game data as an rpm. The problem is that, for any game that uses autodownloader, the data *cannot* be packaged in Fedora because of license reasons.

I've been looking at uqm today to see how we could do this. I did come up with one method that does work (at least in Fedora 13), though it will be a bit of a pain for autodownloader. For uqm, it looks something like this: uqm is in Fedora autodownloader is in Fedora uqm-content is in RPM Fusion Remove Requires: autodownloader from uqm Add Requires: uqm(data) to uqm Add Provides: uqm(data) to autodownloader Add Provides: uqm(data) to uqm-content When installing uqm, if RPM Fusion isn't enabled, autodownloader gets downloaded and installed, and then the game data gets downloaded the first time uqm is run. If RPM Fusion is enabled, yum will prefer uqm-content, which mean uqm will run the first time without needing to download anything. This should consistently work because, in the newer yum versions, one of the tests for choosing which package to install as a dependency is to compare how many letters match (i.e. uqm and uqm-content both start with uqm, while autodownloader doesn't, so uqm-content would be preferred over autodownloader). [...]

On Sun 23 May 2010 5:06:27 am Jonathan Dieter wrote: > I've been looking at uqm today to see how we could do this. I did come > up with one method that does work (at least in Fedora 13), though it > will be a bit of a pain for autodownloader. For uqm, it looks something > like this: > > uqm is in Fedora > autodownloader is in Fedora > uqm-content is in RPM Fusion > > Remove Requires: autodownloader from uqm > Add Requires: uqm(data) to uqm > Add Provides: uqm(data) to autodownloader > Add Provides: uqm(data) to uqm-content > > When installing uqm, if RPM Fusion isn't enabled, autodownloader gets > downloaded and installed, and then the game data gets downloaded the > first time uqm is run. If RPM Fusion is enabled, yum will prefer > uqm-content, which mean uqm will run the first time without needing to > download anything. > > This should consistently work because, in the newer yum versions, one of > the tests for choosing which package to install as a dependency is to > compare how many letters match (i.e. uqm and uqm-content both start with > uqm, while autodownloader doesn't, so uqm-content would be preferred > over autodownloader). > > Do note that there are no conflicts between autodownloader and > uqm-content, so there's no problem if someone installs the game without > RPM Fusion, thus getting autodownloader, and then enables RPM Fusion and > installs uqm-content. The game would proceed to use the content from > uqm-content rather than try to download it with autodownloader. > > The drawback of this method is that, for each game, a new version of > autodownloader will have to be pushed with updated Provides *before* we > can put the game data in RPM Fusion. > > Thoughts? Comments? Stones to throw at me? :) > > Jonathan How does all of this work after autodownloader is already pulled in? If I install uqm without rpmfusion enabled, autodownloader would be installed. Afterwards, I enabled rpmfusion, and install urban-terror, wouldn't autodownloader already Provides urban-terror(data) even though rpmfusion is enabled?

How does all of this work after autodownloader is already pulled in? If I install uqm without rpmfusion enabled, autodownloader would be installed. Afterwards, I enabled rpmfusion, and install urban-terror, wouldn't autodownloader already Provides urban-terror(data) even though rpmfusion is enabled? Ryan

I like this idea, but I think that if possible we should avoid the yum naming rule. I doubt it will change anytime soon (we should ask a yum developer), but I think that versioning is something much more solid we should rely on for this mechanism. I forget if providing a higher version of a capability means it gets pulled automatically on yum update... If not though, this would work well: Add Requires: uqm(data) to uqm Add Provides: uqm(data) = 1 to autodownloader Add Provides: uqm(data) = 2 to uqm-content This way it will be satisfied with autodownloader, but prefer uqm-content by version and by name. Either way, I guess it comes down to whether or not we can trust the naming rule being around for a while. If the yum devs promise it won't go away in the near future, then I think the plan you outlined is great.