0.2.8.0 final: Release process and bugs

[Luke-Jr]

Luke: Docs are not data and therefore, the --prefix argument is used for the placement directly, --datadir has no influence.

Don't most programs work otherwise? Everything is data. --datadir is specifically for *read-only architecture-independent* data, which docs certainly are.

We can add a --docdir switch, but later. Maybe just "--prefix /usr" and no "--disable-games" does what you want? It should

I'll try it... guess I'll need to move files around manually if not.

rcd_config should go where the other scripts are going, into <main program dir>/scripts.

That has only 'sysinstall', and the reason I ask is because I don't see any place installing the scripts in the Makefiles... and I need to debug this "Script directory not found." error, which is looking for scripts in /var/tmp/portage/armagetronad-0.2.8.0_rc4/image//usr/games/usr/share/games/armagetronad/scripts for some reason (this is with --enable-games and --prefix=/usr/games, note). Interestingly enough, changing prefix seems to "fix" it despite the continued lack of rcd_config being anywhere.

Since this is not my system, I can't install an older glibc and force linking with that.

You could statically link to it

[Luke-Jr]

Other pecularities:
- We are now the second program to install an image into /usr/share/icons. Everything else (except abiword) is using hicolor/32x32 (or similar) as IIRC the freedesktop standards specify.
- I can't find an example of a correct location (apparently my other games lack menu entries), but Armagetron Advanced is the only desktop file in /usr/share/applnk directly. All the others are categorized into subdirectories.
- --enable-games fails to use /usr/games/bin instead of /usr/bin (Edit: AA ignores --bindir also >:O)
- We seem to make {/usr/kde/3.3,${HOME}/.kde}/share/{icons,applnk} at some point, without any files in them.
Edit: - sysinstall assumes bindir = prefix/bin; BAD BAD BAD (fixed)
Edit: - I presume we still have exclusive dedicated and client?

[Z-Man]

Please be VERY careful. What we're doing now may not be perfect, but it works. Every change that fixes something in the build runs the risk of breaking two distributions you did not test.

[Luke-Jr]

Please be VERY careful. What we're doing now may not be perfect, but it works. Every change that fixes something in the build runs the risk of breaking two distributions you did not test.

Will keep that in mind, however I suspect that every other distribution is using the defaults for datadir since this hasn't been noticed before. I've got workarounds for the bindir issue.
Any ideas on the kde/share and exclusivity matters?

[Z-Man]

You're right about the change you already did, I think it's harmless. But, say, moving any installation location around would break all rpm build scripts as they require you to give exact paths to stuff. Not really fatal, but annoying.

Exclusivity? Is that the dedicated server vs. client/server hybrid thing? The previous ebuild handled that via use flags, which I'd consider wrong Separate ebuilds for client and server are better.

The KDE icons and applnks are working where they are, if you or gentoo don't like that, either move them or disable them with --disable-desktop, then install them the gentoo way. The autopackage build does this, for example, because autopackage has way more sophisticated tools available.

The reason the rcd_scripts are not installed is that you're building a client only, there is no server to start, hence no scripts to be installed. What gets installed where is controlled from batch/Makefile.am via automake variables.

We don't change /usr/bin to /usr/games/bin because the latter is not in the path on many distributions. /usr/local/games/bin, which would be the bin directory for the default prefix, isn't even in the path on gentoo. What we really should be doing is, of course, to check what IS in the path and only deviate from our consistent scheme if we have to. Something to note for the future. And adapt the relocation code to it, it may get confused. For that matter, it may get confused if you set --bindir to something odd, because it needs to find from the executable path to the data path.

Data vs. docs: documentation isn't read by the program, so IHMO, it's not program data. I'm flexible about this for the furure as I don't really mind, but for 0.2.8.0, the docs should stay where they are.

The "Script directory not found" error is odd, especially the directory it's looking in. It shouldn't have more than one /usr/ part in it. The double /game/ part comes from you explicitly asking for it, it seems Can I get your complete configure line again, and maybe all the output you can gather?

ICYDNK: set ARMAGETRONAD_FAKERELEASE=true before configuring, and your build will be way faster. Ideal for testing system integration.

[Lucifer]

The exclusivity thing is the part where you have to reconfigure after building the client to build the server. Automake supports building different programs from the same sources, but for some reason we put it off. All the stuff to do it is there, though. I suspect the reason it got put off was because you didn't care enough about it, and I just plain forgot about it.

Anyway, we might put that on the list for 0.3, but it's definitely too late to worry about it for 0.2.8.

[Z-Man]

Isn't it so that generally with automake, you're supposed to build outside of the source directory if you want several builds to coexist? You can turn that off? You're right, I didn't care about that enough. Not at all, to be precise I never build software from within the source directory.
If it's just sequential builds, "make distclean" should do the job.

[Luke-Jr]

Exclusivity? Is that the dedicated server vs. client/server hybrid thing? The previous ebuild handled that via use flags, which I'd consider wrong Separate ebuilds for client and server are better.

Separate ebuilds are non-standard for Gentoo and a workaround. While it would work long-term, I hope we can get this issue properly solved sometime in the 0.3 development once and for all.

The KDE icons and applnks are working where they are, if you or gentoo don't like that, either move them or disable them with --disable-desktop, then install them the gentoo way.

Yes, they're fine, but I just noticed that it was a bit unusual... so something to think about before our next stable release. The empty KDE directories, however, are annoyances I'm working to fix.

Data vs. docs: documentation isn't read by the program, so IHMO, it's not program data. I'm flexible about this for the furure as I don't really mind, but for 0.2.8.0, the docs should stay where they are.

I got too frustrated trying to make it work properly with Gentoo, so I'm having the 0.2.8 ebuild do its own doc installation (via dodoc/dohtml) and deleting AA's installed copies.

The "Script directory not found" error is odd, especially the directory it's looking in. It shouldn't have more than one /usr/ part in it.

The make system had the script directory in two separate variable-based paths, thus when they differed, the alignment wasn't correct and the sed command in sysinstall was ignored. I've committed a fix to use the same path throughout the make system.

ICYDNK: set ARMAGETRONAD_FAKERELEASE=true before configuring, and your build will be way faster. Ideal for testing system integration.

What's that do?

[Lucifer]

I envision a day where I can configure once, make once, and make install once, and the result will be a client, a server, and a master server all at once.

[Luke-Jr]

Fixed the empty directory problem-- sysinstall was making directories for all *considered* destination paths, just to check whether it could write there. The new code just makes sure it can write to the rightmost existing directory and only creates the full path when it is chosen as a result.
However, this code isn't nearly as simple as the code it is replacing, and may have portability issues. So if everyone with time could please give it a test run (--enable-sysinstall --with-glout --enable-desktop), preferably with root access (so it has more than a single valid choice) and be sure it installs the desktop icons in a logical place, I'd appreciate it.

[Z-Man]

What's that do?

Skipping compilation and replacing the executable with a dummy shell script.

Lucifer: yes, me too.

[anjori]

Lucifer: Looks like it's the same as this one. Tree built from source, otherwise I'd say it's a library version hell problem as described here. My vmware installation was broken until sunday, I already fetched Ubuntu, FC4 and a debian netinstall CD, all waiting for installation.

anjori: Do you have two systems (one 32 and one 64 bit), did you try to install the 64 bit binary on a 32 bit machine or are you a different anjori than the one from irc?

Ah, shit. I feel really stupid right now. No, I don't have a 64 bit system. Which, of course, would explain why the first autopackage I tried didn't work.

[Z-Man]

Hehe. I'll see whether it's possible to get a better error message for that case

[Luke-Jr]

Isn't it so that generally with automake, you're supposed to build outside of the source directory if you want several builds to coexist? You can turn that off? You're right, I didn't care about that enough. Not at all, to be precise I never build software from within the source directory.
If it's just sequential builds, "make distclean" should do the job.

Ebuilds have isolated 'compile' and 'install' stages. It is not possible to do 'compile','install','compile','install'
Good idea re the separate build dirs, though, that will work.

[Z-Man]

I'll have to revert your two path consistency changes, they broke relocatability. The purpose of the sysinstall script is to rewrite some paths from the compiled prefix ${prefix} to the installation prefix ${PREFIX}. That I'm a braindead zombie is not the only reason why the installation process is so complicated