Is there any way, when upgrading the installed version of UT2004, to get it to realize that all the data files are already installed and that it doesn't actually need all 6 CDs again? It took hours to get installed the first time, and now that there's a new(er) and hopefully less buggy version out, I'd like to be able to just install the new program files and not have to go through with feeding it all the CDs again.
the problem is, what if the user wants to reinstall stuff because they corrupted files ? :) *** This bug has been marked as a duplicate of 24258 ***
re: comment 1, wouldn't an "rm -rf /opt/ut2004" let them do that, if the ebuild was checking for installed files? Or running "emerge -C ut2004 && emerge ut2004"? :)
Actually, a much better resolution to this would have been INVALID. All ebuilds reinstall all files on purpose. I'm sorry that it is such a pain to upgrade packages like ut2004, due to their immense size, but either you grin and bear it, or we remove such packages from portage. There is no middle ground as it would be against the design of portage. The only possible solution would be to get portage doing a *lot* more work and to store a md5 of every file installed by a specific ebuild, this way, portage would be able to verify that a file has not changed since last emerge and would skip the copying of that file. This would allow for patches to only update the files they need to, while the portage version would still be updated. However, doing something like this would be suicide on portage's performance, which has been steadily decreasing as it is already. Not to mention the massive expansion that the portage tree would undergo to accomplish this.
Actually, I just thought of a fairly simple solution that would accomodate both the issue of "portage behavior by design" and the need to be able to reinstall the data files if they become corrupt: Split the install into 2 ebuilds: 1 is for the application files, and so when new patches or fixes are released, it will be updated. The second (which the first depends on) is the 6 CDs of data files, that you only need to install once, but are free to reinstall if they become corrupt. Can anyone see a problem with this system?
Unfortunately, there could be any number of things that are patched, such as new maps, etc. While your method would work for a single patch, what happens when the second patch comes along? Since it would remove all the files from the first patch, you would end up with an incomplete install. To put it simply, this needs portage support. We've already tried to accomodate by allowing for doing an install from the hard drive by overriding CD_ROOT, perhaps you should consider that method.
Well, in most cases (and certainly in older versions of UT), when a new patch comes out, there's a version that operates on the previous version of the app, and a version that operates on the initial version of the app (or a major milestone release). Having an ebuild that always restores the initial app version (from our "ut2004-data" package) and then patches it successively up to the current version should alleviate the issues you've mentioned, while still being a lot lighter than reinstalling 6 CDs of data files.
I'll be honest. I'm not interested in breaking up the ebuild simply because you might find it inconvenient during upgrades. There is no technical merit to the separation of the ebuild. Gentoo does not approve of the splitting of packages like many other distributions do, as it causes more maintenance to keep the versions in sync and working properly.
Can't we just use the nocd use flag to not grab files from the CD ? /Line72
...and what? Force you to copy all the files yourself and also to uncompress them yourself? Honestly, deal with it. It is a portage limitation and until portage is extended to properly support incremental upgrades, I will NOT make any changes to the way ut2004 currently builds.
Closing to clean up after bugzilla upgrade. reopen if closed in error. Thanks.
clean up bug list after bugzilla update
