Prebuilt windows binary AccessControl.dll in source tarball

[megaglest]

Prebuilt windows binary AccessControl.dll in source tarball

[filux]

It is not related with game source and is used only for build installer for windows using nsis http://nsis.sourceforge.net/AccessControl_plug-in (recently on linux) then building it from source is generally pointless and not easy.
What can you tell/advice (besides building from source) for that situation ^.

[apoleon]

On Sat, 31. Jan 15:13 filux [email protected] wrote:

It is not related with game source and is used only for build installer
for windows using nsis
[1]http://nsis.sourceforge.net/AccessControl_plug-in (recently on linux)
then building it from source is generally pointless and not easy.
What can you tell/advice (besides building from source) for that situation
^.
I could give you a better advice if I knew why this plugin is suddenly
required for the build installer for windows. If it is not related to
the game itself, I would normally ship it in some extra tarball
dedicated for Windows, MacOS etc. which can of course contain additional
binaries specific for these platforms. A source tarball should never contain
anything prebuilt except it can be reproducibly built from the
corresponding sources and dll files are useless for Linux users too.

You could replace the binary with a script that downloads the required
files from the internet. Maybe even some kind of documentation might be
sufficient that explains the necessary steps for Windows users.
Splitting of everything unrelated to the game sources into another
tarball would be another idea.

[filux]

Ok, another tarball, but what would you say if "everything unrelated to the game sources" will be inside a git submodule connected to the repository, then we also have separate tarball.
How it will look like from your position, is it acceptable or not?

[apoleon]

On Sat, 31. Jan 22:46 filux [email protected] wrote:

Ok, another tarball, but what would you say if "everything unrelated to
the game sources" will be inside a git submodule connected to the
repository, then we also have separate tarball.
How it will look like from your position, is it acceptable or not?

I only have to ensure that everything in the source tarball is
accompanied by its source. How you want to manage your git repository
(development) is completely up to you. Debian is only concerned about
the source tarball (release) because that's what we are going to
distribute. If you can find a way to move prebuilt binaries into another
tarball, that would be acceptable of course because Debian won't
distribute that.

[tomreyn]

I think this is a misunderstanding. Apoleon is (strongly) recommending that we should ensure there will be no .dll files or any other binaries in a source tarball we make available as the sources a given release was built from. That is, https://github.com/MegaGlest/megaglest-source/releases/download/3.11.0/megaglest-source-3.11.0.tar.xz contains a DLL file and it just should not. And I think he is entirely right on that.

I think this DLL file slipped through because we changed the way we package Windows releases a little bit, and because the DLL file was not explicitly added to the list of files we ensure are not excluded when building source tarballs during releases.

Filux: Should I be wrong about this please let's discuss on IRC first, then let us sum it up here, so we don't make this a lengthy discussion bug (which is no fun for everyone involved in the discussion as well as everyone wading through it later).

But I think this is really just a misconception (and a little bug on our end we should fix in future source code tarball releases).

[filux]

Thanks for answers, now we know all posibilities, and now is time to do something with this bug before the next release.

[filux]

Fixed by adb71b4

[apoleon]

Thanks for fixing this bug. In this way I also wanted to express my gratitude to all of you for your work on this project. I think it is exemplary for being an outstanding and true free software game and I mean this in every respect. Regards, Markus