Module layout proposal: Split kdegames-data from kdegames

[Stefan Majewsky]

On Fri, Oct 14, 2011 at 9:30 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> IMO today with usually broadband internet access this shouldn't be much of a
> concern (especially if these files change only rarely).

For all games, the data contributes 400 MB of uncompressable history.
(I think that's the number, although it would be nice if someone who
already ran the kdegames svn2git rules could confirm this.)

And no, broadband internet access is not yet ubiquituous. Even here in
Germany, there is a non-negligible percentage of people on less than 1
MBit/s (sometimes much less). Also, broadband internet access is in a
non-negligible number of cases over UMTS and thus limited by volume
plans, so also the raw download volume matters very much in a lot of
cases.

>> The same
>> holds true for drive-by contributors: They only have to clone a tiny
>> repo containing the source code of the game which they want to hack
>> on, without fetching megabytes of data files which they already had
>> installed.
>
> Personally I'd say "who cares". At least I don't check anymore how big a
> checkout will be before doing the checkout.

I vote for splitting the data not because I want to save some
bandwidth. It's because we got numerous complaints with the initial
plan to include the data in the Git repos. Among others, I
specifically remember Aaron caring about drive-by contributors.

> I'm not sure I really like this.
> The general trend is to split per-application, so there would be e.g. one
> repository kolf and one for ksquares.
> If data/ goes into one separate repository, this will make it harder once the
> sources are split into multiple repositories.
> Either each small game would depend on all data files, or each small game
> would consist of two packages, one for the data and one for the actual
> program.
> Or will packager take care of this and create nice packages ?

Yes, the plan is that each game should be split into two packages.
I've consciously included kde-packagers@ for their feedback on this
plan. My humble impression is that package dependency solvers are fast
enough nowadays to handle multiple packages even for small apps.

Each game depends on its data files only. That's why each set of data
(per application) shall create its own marker file.
macro_optional_add_subdirectory ensures that partial SVN checkouts
continue to work for cases where the developer needs a more current
version of his specific data files.

>> 2. Setup the buildsystem for kdegames-data using
>> macro_optional_add_subdirectory() as in kdegames, so that data can be
>> selected for installation on a per-application basis. Each set of
>> application data will additionally install an empty marker file which
>> indicates that data is available for this application (something like
>> ${DATA_INSTALL_DIR}/${APP}/hasdata; please suggest better schemes if
>> there are).
>
> Would it be possible to simply check whether the directory exists ?
> ${DATA_INSTALL_DIR}/${APP}/Data/ or something like this ?

When I checked last time, directories were not cleaned up correctly by
the uninstall target.

> Hmm, not sure.
> I'd prefer if it would also build when the data files are not present (since
> they are not required for building).

It would be possible to build, but it would require a flag. This is
what packagers want to do (since they probably build kdegames-data
separately), but for the random user, I want to make it obvious that
something's wrong by not compiling about everything.

Greetings
Stefan