this installs the RotT retail game data. (thought I submitted this a long time ago, but couldn't find it in bug search...) Reproducible: Always Steps to Reproduce:
Created attachment 137518 [details] here it is
*** This bug has been marked as a duplicate of bug 120782 ***
how is this resolved if it's not in portage? is someone making mistakes or did I miss something?
reopen
New version is out 1.1 although suffers rrom the same problems as before although the amd64 flag can now be added
bad value of S pull warning >>> Emerging (1 of 1) games-fps/rott-data-1.0 from local-repo * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * Found CD #1 root at /mnt/cdrom/rottinst/ >>> Unpacking source... /var/tmp/portage/games-fps/rott-data-1.0/temp/environment: line 277: cd: /var/tmp/portage/games-fps/rott-data-1.0/work/rott-data-1.0: No such file or directory
Created attachment 198144 [details] corrected ebuild for rott-data S=${WORKDIR} to avoid warning
Created attachment 240169 [details] games-fps/rott-data-1.0.ebuild
I made a few changes to the rott-data ebuild. Aside from dome general cleanup: 1. I removed the rott dependency as rott should pull in rott-data (through cdinstall), not the other way around 2. I added support for installing from the RotT CD-ROM 3. I quoted variables where appropriate to support spaces in path names 4. I removed the doc use flag, for two reasons: 4a. It installs the game license rather than any "real" documentation 4b. The license is already installed by the rott package under ~/.rott/ Any news on getting this plus the associated rott ebuild in portage? I like the way this combination of ebuilds works much better than the existing portage ebuild.
Created attachment 276725 [details] games-fps/rott-data-1.0.ebuild Made some more changes: 1. Will install all optional level and combat packs available in the source directory. This was done to support the GOG release, which includes a bunch of stuff not available on the original CD. 2. Now handles mixed-case source filenames, again to support the GOG package. 3. Reinstated the doc USE flag as the GOG package, at least, includes some stuff that could be useful. FYI, I also just updated to rott ebuild it bug 200967 to fix some issues with loading the optional packs.
The annoying thing about GOG games, and this one is probably no exception, is that they really do need Wine to extract them. There's no way around it. I thought it would be really useful if Portage could handle this so I managed to pull it off for Settlers 2 in bug #363719. I could adapt it for this but I don't own the GOG version. Maybe you could do it?
(In reply to comment #11) > The annoying thing about GOG games, and this one is probably no exception, is > that they really do need Wine to extract them. There's no way around it. I > thought it would be really useful if Portage could handle this so I managed to > pull it off for Settlers 2 in bug #363719. I could adapt it for this but I > don't own the GOG version. Maybe you could do it? Ha. I hear you. Check out bug 371195. Great minds and all that... :-D I've been using innounp to manually extract the files, and my thought was that having a system-provided package we could depend on would make things easier, allow us to fully automate extraction and installation, etc. I didn't think of bundling innounp with the package, but that'd also work. Either way, I think it's a better solution to requiring users to manually unpack those setup archives, especially since most won't be familiar with innounp. Please feel free to speak up in my bug report if you think innounp itself should or shouldn't be included in portage. Just for the record, though, Inno Setup isn't really a "very unfriendly packaging format." It's meant to be a Windows installer and at that job it works great. I've used it for years for my Windows packages and love it. There unfortunate aspect that there are no native Linux utilities that can handle it does suck, though.
Created attachment 288147 [details] games-fps/rott-data-1.0-r1.ebuild Updated ebuild to include support for directly unpacking the GOG installer, as discussed in bug 371195 and bug 363719. The ebuild now has a cdinstall USE flag, which is enabled by default. So, -cdinstall would need to be set for the GOG package to be installed. This does have the unfortunate side-effect of conflicting somewhat with the rott (binary) ebuild, which also uses cdinstall, though that's used to determine whether the rott-data package gets pulled in. So, to install from CD, you can do this: USE=cdinstall emerge rott But to install from the GOG package, you'll either need to do this: USE=-cdinstall emerge rott rott-data or set this in your package.use: games-fps/rott cdinstall games-fps/rott-data -cdinstall and then: emerge rott Kind of confusing, I know, but it works, and it's the best I could come up with that doesn't involve adding a GOG-specific USE flag (which really might not be that bad of an idea if support for it picks up...).
Created attachment 288149 [details] rott-data Manifest Also attaching Manifest file containing GOG package checksum, which I think will be needed if you don't have it available, even if you install from CD.
Created attachment 288151 [details] games-fps/rott-data-1.0-r1.ebuild minor cleanup
Hello again. :) Unfortunately all this fell a little way down my priority list but I haven't forgotten about it. I do think the approach you've taken is very confusing. I still stand by the suggestion I made previously. Make rott depend on rott-data either unconditionally (perhaps using PDEPEND) or not at all (simply suggest it). Use the cdinstall flag on the rott-data ebuild to mean install from CD when enabled or download from GOG when disabled. If the user wants to install from local files then they can just enable cdinstall while passing CD_ROOT. If you did make rott-data a dependency but the user still insists on installing the files manually (which I don't recommend) then they can add games-action/rott-data-1.0-r1 to /etc/portage/profile/package.provided.
Attaching updated ebuilds. rott - does away with cdinstall USE flag, as suggested by James. Data file selection is now controlled by the demo USE flag. With USE=-demo (default), rott-data is pulled in. With USE=demo, rott-data is explicitly blocked. rott-data - Switched to using innoextract for unpacking the GOG installer rather than innounp. innoextract is a native Linux binary, so it's faster, less complicated, and doesn't depend on wine. Also now inherits cdrom.eclass, which is required for cdrom handling functions.
Created attachment 324458 [details] games-fps/rott-data-1.0-r1.ebuild
sorry for the noise, but I forgot there's a separate bug for the rott engine ebuild. Posting the updated ebuild for that to bug 245885 instead of here.
Great work, Jared! I'd been meaning to start using innoextract for these games. I feel less dirty now. ;)
Sorry, I still don't understand why portage is missing rott-data?
join guru and put it there https://wiki.gentoo.org/wiki/Project:GURU
