Hi
Vavoom has already been packaged for a long time in Fedora and uses autodownloader for enabling users to use the shareware data easily. I have recently packaged a alternative Doom engine called Chocolate Doom [2] which is a more conservative port that aims to be more compatible with mods. I could package other Doom engines out there including odamex[2], some of them unique. It doesn't make much sense to duplicate the autodownloader related files. Debian has some guidelines [3] What would be the best way to handle this?
References:
1. https://bugzilla.redhat.com/show_bug.cgi?id=730851 2. http://odamex.net/ 3. http://pkg-games.alioth.debian.org/doom-packaging/
Rahul
Hi
Vavoom has already been packaged for a long time in Fedora and uses autodownloader for enabling users to use the shareware data easily. I have recently packaged a alternative Doom engine called Chocolate Doom [2] which is a more conservative port that aims to be more compatible with mods. I could package other Doom engines out there including odamex[2], some of them unique. It doesn't make much sense to duplicate the autodownloader related files. Debian has some guidelines [3] What would be the best way to handle this?
References:
Disclaimers, I've not looked at any of this, and I use prboom. :)
My memory of autodownloader is that it checks for the existence of some file, if it's there, it does nothing and runs the program, and if not, if downloads it and then runs the program. Could we not do this is such a way that chocolate uses the same directory stucture for the user-specific downloaded files as vavoom does? If not, we could at least use vavoom's structure for the autodownloader portion and symlink from the places chocolate expects. Then, even if the user uses chocolate first, if they run vavoom as is currently packaged, it sees what it wants and Bob's your uncle.
Does this make sense?
-J
Rahul _______________________________________________ games mailing list games@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/games
On 08/20/2011 08:48 PM, Jon Ciesla wrote:
Then, even if the user uses chocolate first, if they run vavoom as is currently packaged, it sees what it wants and Bob's your uncle. Does this make sense? -J
You are asking the user to install two different engines then because the autodownloader files are part of vavoom package.
Rahul
On 08/20/2011 08:48 PM, Jon Ciesla wrote:
Then, even if the user uses chocolate first, if they run vavoom as is currently packaged, it sees what it wants and Bob's your uncle. Does this make sense? -J
You are asking the user to install two different engines then because the autodownloader files are part of vavoom package.
No, I'm not. The files vavoom would want the user to download are not owned by the vavoom package, they're in the user's ~, are they not?
Rahul _______________________________________________ games mailing list games@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/games
On 08/20/2011 11:08 PM, Jon Ciesla wrote:
No, I'm not. The files vavoom would want the user to download are not owned by the vavoom package, they're in the user's ~, are they not?
I am talking about doom-shareware.desktop and doom.autodlrc and you are talking about the data it downloads
Rahul
On 08/20/2011 11:08 PM, Jon Ciesla wrote:
No, I'm not. The files vavoom would want the user to download are not owned by the vavoom package, they're in the user's ~, are they not?
I am talking about doom-shareware.desktop and doom.autodlrc and you are talking about the data it downloads
Right. I'm saying each RPM could have it's own versions of those two files, which use the same paths in the user's ~.
Rahul _______________________________________________ games mailing list games@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/games
On 08/20/2011 11:22 PM, Jon Ciesla wrote:
On 08/20/2011 11:08 PM, Jon Ciesla wrote:
No, I'm not. The files vavoom would want the user to download are not owned by the vavoom package, they're in the user's ~, are they not?
I am talking about doom-shareware.desktop and doom.autodlrc and you are talking about the data it downloads
Right. I'm saying each RPM could have it's own versions of those two files, which use the same paths in the user's ~
Now we are going in a bit of a circle. To reiterate what I asked in the first mail, I am asking if there is a better alternative to just duplicating these files? Why? Because I just built a vavoom update and had to fix doom.autodlrc because one of the mirrors was not valid anympore. Now if there are multiple engines packaged, such a fix would have to be propagated across three or more packages depending on how many "ports" aka different doom engines gets packaged.
Rahul
On 08/20/2011 11:22 PM, Jon Ciesla wrote:
On 08/20/2011 11:08 PM, Jon Ciesla wrote:
No, I'm not. The files vavoom would want the user to download are not owned by the vavoom package, they're in the user's ~, are they not?
I am talking about doom-shareware.desktop and doom.autodlrc and you are talking about the data it downloads
Right. I'm saying each RPM could have it's own versions of those two files, which use the same paths in the user's ~
Now we are going in a bit of a circle. To reiterate what I asked in the first mail, I am asking if there is a better alternative to just duplicating these files? Why? Because I just built a vavoom update and had to fix doom.autodlrc because one of the mirrors was not valid anympore. Now if there are multiple engines packaged, such a fix would have to be propagated across three or more packages depending on how many "ports" aka different doom engines gets packaged.
I thought you meant duplicating the data files only. You could put the autodlrc in a -common package for one of the engines that both require. Make it so chocolate would require vavoom-data-common or whatever, as would vavoom, but chocolate wouldn't require vavoom proper.
Rahul _______________________________________________ games mailing list games@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/games
On 08/20/2011 11:39 PM, Jon Ciesla wrote
I thought you meant duplicating the data files only.
I did clarify again what I meant in my previous mail.
You could put the autodlrc in a -common package for one of the engines that both require. Make it so chocolate would require vavoom-data-common or whatever, as would vavoom, but chocolate wouldn't require vavoom proper.
doom.autodlrc is not specific to vavoom. So don't see why a common data package would be called that.
Rahul
On 08/20/2011 11:39 PM, Jon Ciesla wrote
I thought you meant duplicating the data files only.
I did clarify again what I meant in my previous mail.
You could put the autodlrc in a -common package for one of the engines that both require. Make it so chocolate would require vavoom-data-common or whatever, as would vavoom, but chocolate wouldn't require vavoom proper.
doom.autodlrc is not specific to vavoom. So don't see why a common data package would be called that.
That's not a requirement, just a way to get away with not making a separate SRPM. That might be best, actually, maybe doom-shareware-data or somesuch?
If you want to make it, I can review it.
-J
Rahul _______________________________________________ games mailing list games@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/games
On 08/20/2011 11:49 PM, Jon Ciesla wrote:
That's not a requirement, just a way to get away with not making a separate SRPM. That might be best, actually, maybe doom-shareware-data or somesuch?
If you want to make it, I can review it.
That would be a bit of a misleading name since it only has the autodownloader files and not the data. There was a discussion earlier in RPM Fusion list about packaging the shareware data there and potentially dropping the autodownloader files. If we want to continue to package the autodownloader files separately, the name should be more specific
Rahul
On 08/20/2011 11:49 PM, Jon Ciesla wrote:
That's not a requirement, just a way to get away with not making a separate SRPM. That might be best, actually, maybe doom-shareware-data or somesuch?
If you want to make it, I can review it.
That would be a bit of a misleading name since it only has the autodownloader files and not the data. There was a discussion earlier in RPM Fusion list about packaging the shareware data there and potentially dropping the autodownloader files. If we want to continue to package the autodownloader files separately, the name should be more specific
I don't think that's a good plan, it would make the engines in Fedora either unplayable or require RPMFusion, which we can't do.
Rahul _______________________________________________ games mailing list games@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/games
On 08/20/2011 11:58 PM, Jon Ciesla wrote:
I don't think that's a good plan, it would make the engines in Fedora either unplayable or require RPMFusion, which we can't do.
Not really. Quake 3 engine (ioquake3) has OpenArena and Doom engines have Freedoom. So they aren't unplayable
Rahul
On 08/20/2011 11:58 PM, Jon Ciesla wrote:
I don't think that's a good plan, it would make the engines in Fedora either unplayable or require RPMFusion, which we can't do.
Not really. Quake 3 engine (ioquake3) has OpenArena and Doom engines have Freedoom. So they aren't unplayable
Oh, I see. Gotcha.
Rahul _______________________________________________ games mailing list games@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/games
Hi,
On 08/20/2011 04:17 AM, Rahul Sundaram wrote:
Hi
Vavoom has already been packaged for a long time in Fedora and uses autodownloader for enabling users to use the shareware data easily. I have recently packaged a alternative Doom engine called Chocolate Doom [2] which is a more conservative port that aims to be more compatible with mods. I could package other Doom engines out there including odamex[2], some of them unique. It doesn't make much sense to duplicate the autodownloader related files. Debian has some guidelines [3] What would be the best way to handle this?
References:
First of all thanks for doing the vavoom update!
Now about this thread (which I've read entirely but I was not sure where to jump in).
I think it would make sense to have a single common package for autodownload files, .desktop files and .sh files, we need to figure out what to do with the .sh files when multiple engines are installed (pick a default, add a switch to allow overriding it from the cmdline I guess). I suggest calling it "doom-autodownload-helpers".
As for the interaction with doom-shareware from rpmfusion, we could make it first check if that is installed, and if so not check for the files under ~ and use autodownload to get them at all, instead simply launching $engine with the necessary options to use the files under /usr/share put there by the rpmfusion package.
Regards,
Hans
On 08/21/2011 08:29 AM, Hans de Goede wrote:
First of all thanks for doing the vavoom update!
You are welcome. Do review the changes because I was doing it fairly blindly. FYI, I have been discussing with freedoom upstream about doing more regular releases and have updated the current package to the latest git snapshot locally. I will post the changes for review after I get some input from upstream.
As for the interaction with doom-shareware from rpmfusion, we could make it first check if that is installed, and if so not check for the files under ~ and use autodownload to get them at all, instead simply launching $engine with the necessary options to use the files under /usr/share put there by the rpmfusion package.
I think you are in a better position to do what it is necessary here but I will be happy to review any new packages. I have already built Chocolate Doom for Rawhide and Fedora 16 and have been reading up on the status of the various Doom "ports" for the last few days to figure out which ones to package. I will post on a update on that too a bit later.
Rahul
Ps: In case anyone is wondering, Doom was one of the games I spend a lot of time with in a previous life and recent news of the upcoming Doom 3 engine source release motivated me to get involved with Doom again now.
On 08/21/2011 08:29 AM, Hans de Goede wrote:
First of all thanks for doing the vavoom update!
You are welcome. Do review the changes because I was doing it fairly blindly. FYI, I have been discussing with freedoom upstream about doing more regular releases and have updated the current package to the latest git snapshot locally. I will post the changes for review after I get some input from upstream.
As for the interaction with doom-shareware from rpmfusion, we could make it first check if that is installed, and if so not check for the files under ~ and use autodownload to get them at all, instead simply launching $engine with the necessary options to use the files under /usr/share put there by the rpmfusion package.
I think you are in a better position to do what it is necessary here but I will be happy to review any new packages. I have already built Chocolate Doom for Rawhide and Fedora 16 and have been reading up on the status of the various Doom "ports" for the last few days to figure out which ones to package. I will post on a update on that too a bit later.
Rahul
Ps: In case anyone is wondering, Doom was one of the games I spend a lot of time with in a previous life and recent news of the upcoming Doom 3 engine source release motivated me to get involved with Doom again now.
Having written a Makefile calling deutex and bsp, I'd say you don't need an excuse. ;)
games mailing list games@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/games
Hi,
On 08/21/2011 05:06 AM, Rahul Sundaram wrote:
On 08/21/2011 08:29 AM, Hans de Goede wrote:
First of all thanks for doing the vavoom update!
You are welcome. Do review the changes because I was doing it fairly blindly. FYI, I have been discussing with freedoom upstream about doing more regular releases and have updated the current package to the latest git snapshot locally. I will post the changes for review after I get some input from upstream.
As for the interaction with doom-shareware from rpmfusion, we could make it first check if that is installed, and if so not check for the files under ~ and use autodownload to get them at all, instead simply launching $engine with the necessary options to use the files under /usr/share put there by the rpmfusion package.
I think you are in a better position to do what it is necessary here but I will be happy to review any new packages.
I'm not so sure about me being in a better position, I really don't have much time if any at all atm to work on this (proof of point, see how long it has taken me to get around to answering this mail).
So if possible it would be great if you could make the necessary changes, I will happily help were I can. I think putting the autodl and launch scripts into a new doom-common package is a good idea.
I have already built Chocolate Doom for Rawhide and Fedora 16 and have been reading up on the status of the various Doom "ports" for the last few days to figure out which ones to package. I will post on a update on that too a bit later.
Regards,
Hans
On 08/29/2011 12:07 AM, Hans de Goede wrote:
So if possible it would be great if you could make the necessary changes, I will happily help were I can. I think putting the autodl and launch scripts into a new doom-common package is a good idea.
The launch script refers to vavoom by name and I am not sure how to package that generically so that it could use alternative engines but do take a look at what I have done
http://sundaram.fedorapeople.org/packages/doom-autodownloader-0.1-1.fc15.src...
Rahul
Hi,
On 08/29/2011 03:43 PM, Rahul Sundaram wrote:
On 08/29/2011 12:07 AM, Hans de Goede wrote:
So if possible it would be great if you could make the necessary changes, I will happily help were I can. I think putting the autodl and launch scripts into a new doom-common package is a good idea.
The launch script refers to vavoom by name and I am not sure how to package that generically so that it could use alternative engines but do take a look at what I have done
http://sundaram.fedorapeople.org/packages/doom-autodownloader-0.1-1.fc15.src...
Sorry for the slow reply. I've taken a quick look, the basis looks good, some remarks: 1) What provides /usr/bin/doom-engine, is the intend to use alternatives for this? I think that is a good idea, but we then need to also provide a wrapper script per engine with standardized cmdline options for specifying for example the datadir where the wad files are. As the actual options for this may differ per engine. We could try to see if there is some compatibility between at least chocolate and vavoom and choose to use a compatible option (if available) in the download + launch script to avoid the need for a wrapper script. 2) I had the idea that we would also move the heretic shareware, hexen demo and strife-demo autodl and launch scripts there. They could then use their own /usb/bin/heretic-engine, etc. for this which would again be provided by alternatives. My reasons fir suggesting also moving these there, are: a) It is consistent b) AFAIK other doom engines can play for example heretic too
So how to move forward with this. I'm afraid I've other priorities, so I hope you can make some time for this. If you can do a new version based on the above comments, and also a proposed patch for vavoom to move vavoom over to using this, then I'll review the new package and add the changes to vavoom, does that sound like a good idea?
Note I promise to be quicker with responding the next time around.
Regards,
Hans
On 10/02/2011 09:43 PM, Hans de Goede wrote:
So how to move forward with this. I'm afraid I've other priorities, so I hope you can make some time for this. If you can do a new version based on the above comments, and also a proposed patch for vavoom to move vavoom over to using this, then I'll review the new package and add the changes to vavoom, does that sound like a good idea?
Note I promise to be quicker with responding the next time around.
I am busy with FUDCon India work now but I will provide a revised version when I find time. It is not a problem if you take time to reply. This isn't urgent work by any standard.
Rahul
-
Hans de Goede -
Jon Ciesla -
Rahul Sundaram