* [gentoo-dev] Re: Enemy Territory and Gentoo
[not found] ` <20030922144445.21c20f1c.ttimo@idsoftware.com>
@ 2003-09-22 13:12 99% ` Chris Gianelloni
0 siblings, 0 replies; 1+ results
From: Chris Gianelloni @ 2003-09-22 13:12 UTC (permalink / raw
To: Timothee Besset; +Cc: megastep, gentoo-dev, games, gentoo-core, jcarmack, locki
[-- Attachment #1: Type: text/plain, Size: 11096 bytes --]
On Mon, 2003-09-22 at 08:44, Timothee Besset wrote:
> Sigh. Let's go over this a third time. --keep is intended to be used when
> it's a matter of fixing up things, not for the everyday user to go with.
> The ebuilds should put the .run on the HD, and put a wrapper script called
> 'et', which will then spawn the .run the first time it's being called so
> the the UI is displayed and the interactive setup executes (including the
> EULA prompt).
Thanks, anyway. As I have said before, if we do not have control of
exactly where the files go, then there is ZERO point in having an ebuild
at all, since portage will be unable to track the files. If our package
manager cannot track the files, why bother having a "package" at all?
The .run files do end up on the user's drive, in
/usr/portage/distfiles. What I am attempting to do is to perform the
same functions as the scripts within the Makeself archive. I am running
into problems because ONLY the gtk version of the installer does not
segfault. The command-line portion of loki_setup will suit my needs
*perfectly*, but since it segfaults, it is no use to me.
It basically boils down to this: if the user can choose where to install
the package (versus us telling it where), then it is useless for us to
try to create an ebuild for it.
> I will update the packages once again to fix that head thing when I find
> the time. It might take a week or two. With a wrapper script you can go
> around this when you spawn the .run anyway, either by faking a different
> head binary, or maybe with the right env vars:
>
> "For example, if you are running older software that assumes an older
> version of POSIX and uses `sort +1', `head -1', or `tail +1', you can work
> around the compatibility problems by setting `_POSIX2_VERSION=199209' in
> your environment." (I did not verify that this is working, taken from the
> docs)
>
> If that's not good enough, then just remove the files from ebuild.
It appears that the only course of action we have left to remain good
members of the community is to remove all id games from portage. If
there is someone else I should talk to about this, let me know so I can
contact them. We appear to be at an impass since neither of us appears
to be getting through to the other.
> In the long run I'd like to have loki_setup use data files like win32 does
> .msi files, that is having the installer engine compiled on the target
> machine, and processing a data-only thing. That would probably keep us
> safer from those endless ABI and app compability issues. I don't see when
> I would have time to do that though.
This would be quite cool, but would not solve any of the issues that are
at hand.
If there were a way to "force" the gtk installer to install the binaries
and installations into certain directories, via the -b and -i options
which are available to the command-line version, then there would be no
issue here. I could use the loki_setup installer, have it display the
EULA, and install where *I* tell it to via the ebuild.
To be honest, I simply don't see how if I were to change the ebuild to
display the EULA and force the user to accept before continuing does not
meet the licensing requirements. Since I have repeated this and gotten
no real response on it specifically other than you repeating about a
wrapper, I am assuming that this is not acceptable to meet the license.
I thank you for your time and for your great work in keeping gaming
alive on Linux.
Good day.
Chris Gianelloni
> regards
>
> TTimo
>
> On 19 Sep 2003 09:54:46 -0400
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
>
> > On Fri, 2003-09-19 at 09:27, Timothee Besset wrote:
> > > You DO modify the installer, otherwise there would be no question of
> > > EULA display or not. The EULA has to be displayed if the original .run
> > > is executed as is. Yes, it means ET has to be installed interactively
> > > with an actual agreement of the end user, that what the lawyers want ..
> >
> > Once again, the .run file has the same md5sum as one downloaded from a
> > normal mirror. The ebuild downloads the files from the same mirrors a
> > user would. My dilemma comes in the fact that all applications in
> > Gentoo need to have a non-interactive installation. I *can* break that
> > by REQUIRING a user agree to a displayed EULA before installtion
> > continues, but I cannot allow the ebuild to simply run the .run simply
> > because our package management system would have zero knowledge of the
> > files installed by ET on the live file-system. This is not acceptable.
> > I have proposed a method where a EULA is displayed before installation
> > continues.
> >
> > The Gentoo ebuild does not modify a single file in the Enemy Territory
> > distribution. It simply unpacks the Makeself binary into a temporary
> > directory, then copies files to the destination sandbox before putting
> > moving the files onto the live file-system. Everything is simply a
> > copy. The only "modification" done at all is a final chmod games.games
> > on all of the files once installation is completed.
> >
> > This would all be solved if the loki_setup -n would not Segmentation
> > Fault when run. I have no problems using the loki_setup if it would
> > work properly with -n -b and -i, but it does not.
> >
> > Is making the user agree to the EULA sufficient?
> >
> > If not, then I will be forced to remove all id software from Gentoo due
> > to licensing problems. Please advise me as quickly as possible so I can
> > work to make Gentoo compliant as quickly as possible.
> >
> > > The situation is unchanged really, I think you should put the .run on
> > > the system, with a fake 'et' script, which will spawn the .run the first
> > > time it is executed interactively.
> >
> > We DO put the .run on the system. However, we simply execute it via
> > portage, so there are sufficient rights to install the game for all
> > users to use and also so the files installed by the game are tracked via
> > our package management system for easy removal or upgrade. The
> > setup.gtk binary is not sufficient for portage to track the files. The
> > setup binary (with -b and -i) would be, but it seems to segfault when
> > attempted.
> >
> > For this reason, if a compromise cannot be reached, I will remove all id
> > games from portage, simply because there is zero reason to have them in
> > portage at all if portage cannot track their versions and files
> > properly. It would then be up to the user to download and install the
> > game normally.
> >
> > At this time, it appears that there are 12 ebuilds which would need to
> > be removed. This includes Return to Castle Wolfenstein, Quake 3 Arena
> > (and all of its mods, since the dependency tree would be broken
> > otherwise), and Enemy Territory.
> >
> > Let me know what I should do.
> >
> > > regards
> > >
> > > TTimo
> > >
> > > Chris Gianelloni wrote:
> > >
> > > >I am resending this since I got no response from the first one sent
> > > >Monday. I would love to get this resolved as soon as possible.
> > > >
> > > >On Mon, 2003-09-15 at 09:12, Timothee Besset wrote:
> > > >
> > > >
> > > >>There are two main requirements with everything we release:
> > > >>
> > > >>- Unmodified installer, the files should be distributed the same as we
> > > >>release them, specially regarding the End User License Agreement prompt.
> > > >>
> > > >>
> > > >
> > > >We do not modify the installer. Would us adding a display of the EULA
> > > >and forcing the user to agree before unpacking/installing suffice? If
> > > >not, I can rewrite the ebuild to possibly make use of loki_setup doing
> > > >most of the work unattended. The problem lies in the variable ways in
> > > >which Gentoo installs. All installations take place in a sandbox and
> > > >are only moved to the live filesystem once the install process has
> > > >completed with no errors. Otherwise, there is no way for portage to
> > > >track the files that are changed on the local disk without considerable
> > > >cost in developer time.
> > > >
> > > >
> > > >
> > > >>- Only electronic redistributions. Which means files should never be
> > > >>printed on CD without explicit permission from us.
> > > >>
> > > >>
> > > >
> > > >Gentoo Games is commercial entity independent of the distribution and
> > > >the distribution's Games Team. The Games Team of the distribution will
> > > >work with you to quickly resolve this problem. Any correspondence about
> > > >Gentoo Games should be directed to Daniel Robbins
> > > >(drobbins@gentoo.org). I know that all releases from Gentoo Games are
> > > >done electronically at this time.
> > > >
> > > >
> > > >
> > > >>We use loki_setup installer because we are not distribution centric. Doing
> > > >>a .deb .rpm .whatever for each release would be a pain, and we don't want
> > > >>to do that. And we don't want others doing it for us because we would
> > > >>still get bug reports about those modified installers, and still waste
> > > >>some time.
> > > >>
> > > >>loki_setup has many issues, I can't say I'm really happy with it. But we
> > > >>will stick to it. The main issues with it seem to be ABI brokeness in
> > > >>newer distributions, and misc issues like the 'head' thing. If you really
> > > >>want to have an ebuild with ET, what I'd suggest doing is wrap the
> > > >>download of the .run, and execute it for installation.
> > > >>
> > > >>
> > > >
> > > >If my suggestion above will not suffice, this may be our only option
> > > >aside from removing id games altogether.
> > > >
> > > >I will also be forwarding this (and all future) correspondence to the
> > > >gentoo-core private mailing list for the Gentoo developers. I will pass
> > > >any questions the other developers may have on to you.
> > > >
> > > >
> > > >
> > > >>regards
> > > >>
> > > >>TTimo
> > > >>
> > > >>On 14 Sep 2003 14:51:37 -0400
> > > >>Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > > >>
> > > >>
> > > >>
> > > >>>I was just made aware of the issue with Enemy Territory and the EULA as
> > > >>>it concerns Gentoo. As the maintainer of this package, I would like to
> > > >>>work with you on a resolution. At this time, I have blocked the package
> > > >>>from installing in portage until a resolution can be made. Get back to
> > > >>>me as soon as you get a chance so we can resolve this quickly.
> > > >>>
> > > >>>Thanks,
> > > >>>
> > > >>>--
> > > >>>Chris Gianelloni
> > > >>>Developer, Gentoo Linux
> > > >>>Games Team
> > > >>>
> > > >>>Is your power animal a penguin?
> > > >>>
> > > >>>
> > > >>>
> > --
> > Chris Gianelloni
> > Developer, Gentoo Linux
> > Games Team
> >
> > Is your power animal a pengiun?
> >
--
Chris Gianelloni
Developer, Gentoo Linux
Games Team
Is your power animal a pengiun?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <1063565497.29404.1.camel@localhost>
[not found] ` <20030915151202.5a4ebf28.ttimo@idsoftware.com>
[not found] ` <1063977016.5558.16.camel@localhost>
[not found] ` <3F6B0447.2090907@idsoftware.com>
[not found] ` <1063979686.5834.36.camel@localhost>
[not found] ` <20030922144445.21c20f1c.ttimo@idsoftware.com>
2003-09-22 13:12 99% ` [gentoo-dev] Re: Enemy Territory and Gentoo Chris Gianelloni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox