[gentoo-dev] Enemy Territory ebuild

[gentoo-dev] Enemy Territory ebuild

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

I want to ask the opinion of everyone.  I updated Enemy-Territory
yesterday to close two bugs.  In doing so, I made the decision to make
the newest version of Enemy Territory use the new full download.  I have
had requests from people to have the full download, rather than the
original download + patches, as the ebuild.

Well, I am thinking of breaking up the enemy-territory ebuilds into two
ebuilds.  There would be an enemy-territory ebuild, which would use the
original download + patches (and therefore be dial-up friendly) and the
enemy-territory-full ebuild, which would always download and install the
complete game from the most recent version.  This should satisfy both
camps and also make the ebuild a bit more dial-up friendly.

Thoughts? Opinions? Flames?

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Enemy Territory ebuild

[Michael Sterrett -Mr. Bones.-]

On Sat, 18 Oct 2003, Chris Gianelloni wrote:

> Well, I am thinking of breaking up the enemy-territory ebuilds into two
> ebuilds.  There would be an enemy-territory ebuild, which would use the
> original download + patches (and therefore be dial-up friendly) and the
> enemy-territory-full ebuild, which would always download and install the
> complete game from the most recent version.  This should satisfy both
> camps and also make the ebuild a bit more dial-up friendly.
> 
> Thoughts? Opinions? Flames?

I don't see any reason to have two packages in portage that end up
installing the same thing, especially for a game.  I say, pick one or
the other - full download or patched download, but not both.

Michael Sterrett
  -Mr. Bones.-
mr_bones_@gentoo.org


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Enemy Territory ebuild

[Matt Thrailkill]

How do the kernel ebuilds do it, where they decide whether to patch you
up to a given kernel or just to download the whole thing?  Is it
possible to use that logic with ET?

On Sat, 2003-10-18 at 06:30, Chris Gianelloni wrote:
> I want to ask the opinion of everyone.  I updated Enemy-Territory
> yesterday to close two bugs.  In doing so, I made the decision to make
> the newest version of Enemy Territory use the new full download.  I have
> had requests from people to have the full download, rather than the
> original download + patches, as the ebuild.
> 
> Well, I am thinking of breaking up the enemy-territory ebuilds into two
> ebuilds.  There would be an enemy-territory ebuild, which would use the
> original download + patches (and therefore be dial-up friendly) and the
> enemy-territory-full ebuild, which would always download and install the
> complete game from the most recent version.  This should satisfy both
> camps and also make the ebuild a bit more dial-up friendly.
> 
> Thoughts? Opinions? Flames?


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Enemy Territory ebuild

[Stroller]

On Oct 18, 2003, at 2:30 pm, Chris Gianelloni wrote:

> I want to ask the opinion of everyone.....
>
> Well, I am thinking of breaking up the enemy-territory ebuilds into two
> ebuilds.  There would be an enemy-territory ebuild, which would use the
> original download + patches (and therefore be dial-up friendly) and the
> enemy-territory-full ebuild, which would always download and install 
> the
> complete game from the most recent version.  This should satisfy both
> camps...

Why not have a new USE flag, called "patches", which says to patch the 
original source if possible..?

After all, one can never have enough USE flags.   ;-P

Stroller.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Enemy Territory ebuild

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 612 bytes --]

On Oct 18, 2003, at 2:30 pm, Chris Gianelloni wrote:
> Well, I am thinking of breaking up the enemy-territory ebuilds into two
> ebuilds.  There would be an enemy-territory ebuild, which would use the
> original download + patches (and therefore be dial-up friendly) and the
> enemy-territory-full ebuild, which would always download and install the
> complete game from the most recent version.  This should satisfy both
> camps and also make the ebuild a bit more dial-up friendly.

breaking up a package into full and patch versions is wrong ... so many 
packages could be done like this ...
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Enemy Territory ebuild

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 18 October 2003 07:27 pm, Matt Thrailkill wrote:
> How do the kernel ebuilds do it, where they decide whether to patch you
> up to a given kernel or just to download the whole thing?  Is it
> possible to use that logic with ET?
Unless I'm mistaken, the kernel ebuilds *always* download the whole thing, 
except in cases when it is only available as a patch.
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/kdYKZl/BHdU+lYMRAte4AJ456YdK9rMbCiR69KX1+JdkwqS/HQCfSXQm
SUakVoPkoQHVaBnq9Tj/dN4=
=V1lT
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Enemy Territory ebuild

[Corvus Corax]

Am Sat, 18 Oct 2003 09:30:36 -0400
schrieb Chris Gianelloni <wolf31o2@gentoo.org>:

> I want to ask the opinion of everyone.  I updated Enemy-Territory
> yesterday to close two bugs.  In doing so, I made the decision to make
> the newest version of Enemy Territory use the new full download.  I have
> had requests from people to have the full download, rather than the
> original download + patches, as the ebuild.
> 
> Well, I am thinking of breaking up the enemy-territory ebuilds into two
> ebuilds.  There would be an enemy-territory ebuild, which would use the
> original download + patches (and therefore be dial-up friendly) and the
> enemy-territory-full ebuild, which would always download and install the
> complete game from the most recent version.  This should satisfy both
> camps and also make the ebuild a bit more dial-up friendly.
> 
> Thoughts? Opinions? Flames?
> 
> -- 
> Chris Gianelloni
> Developer, Gentoo Linux
> Games Team
> 
> Is your power animal a penguin?
> 

I'd say, pack it into one ebuild and make it intelligent, some check like
"if an old tar.gz is already installed, download just the needed patches and patch,
but if it has to be downloaded anyway, download the newer "full" installation"
that saves the users from having to download both,
for example when installing the original .56 yesterday
and upgrading from .56 to .56-r1 today (grrrrr)

Corvus

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Enemy Territory ebuild

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

On Sat, 2003-10-18 at 15:38, Stroller wrote:
> On Oct 18, 2003, at 2:30 pm, Chris Gianelloni wrote:
> 
> > I want to ask the opinion of everyone.....
> >
> > Well, I am thinking of breaking up the enemy-territory ebuilds into two
> > ebuilds.  There would be an enemy-territory ebuild, which would use the
> > original download + patches (and therefore be dial-up friendly) and the
> > enemy-territory-full ebuild, which would always download and install 
> > the
> > complete game from the most recent version.  This should satisfy both
> > camps...
> 
> Why not have a new USE flag, called "patches", which says to patch the 
> original source if possible..?
> 
> After all, one can never have enough USE flags.   ;-P

I try to avoid USE flags if at all possible.  It makes things harder to
maintain.  Especially if in the future, the older download will
disappear from mirrors, which we've already started to see.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Enemy Territory ebuild

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 3110 bytes --]

On Sun, 2003-10-19 at 09:31, Corvus Corax wrote:
> Am Sat, 18 Oct 2003 09:30:36 -0400
> schrieb Chris Gianelloni <wolf31o2@gentoo.org>:
> 
> > I want to ask the opinion of everyone.  I updated Enemy-Territory
> > yesterday to close two bugs.  In doing so, I made the decision to make
> > the newest version of Enemy Territory use the new full download.  I have
> > had requests from people to have the full download, rather than the
> > original download + patches, as the ebuild.
> > 
> > Well, I am thinking of breaking up the enemy-territory ebuilds into two
> > ebuilds.  There would be an enemy-territory ebuild, which would use the
> > original download + patches (and therefore be dial-up friendly) and the
> > enemy-territory-full ebuild, which would always download and install the
> > complete game from the most recent version.  This should satisfy both
> > camps and also make the ebuild a bit more dial-up friendly.
> > 
> > Thoughts? Opinions? Flames?
> > 
> > -- 
> > Chris Gianelloni
> > Developer, Gentoo Linux
> > Games Team
> > 
> > Is your power animal a penguin?
> > 
> 
> I'd say, pack it into one ebuild and make it intelligent, some check like
> "if an old tar.gz is already installed, download just the needed patches and patch,
> but if it has to be downloaded anyway, download the newer "full" installation"
> that saves the users from having to download both,
> for example when installing the original .56 yesterday
> and upgrading from .56 to .56-r1 today (grrrrr)

First off, if you notice, the only change is in installation.  The
actual end result is the same.  I really should *not* have bumped the
revision on the package, since the only changes are to the installation
packaging and not to the final game.  To be honest, I shouldn't have
bothered to change anything, since ours was working fine.  There are
simply some people out there who see that there is a new version of
something and immediately file bugs for them without researching the
actual changes.  I just went and completed the bug without looking into
it too heavily.  Once I started getting people complaining about the
changes to the ebuild (downloading the new full version and not
patching), I looked into it more closely and saw that the ONLY change
was to the makeself archive itself and not to the actual game.

At this point, I don't really know what I should do.  Should I simply
leave things how they are and not worry about it at all until a new
revision of the game is released?  Should I mask the new ebuild?  Remove
the old?

I am inclined to just leave things as they are now saying "What's done
is done" and just being glad that we even have this game in portage
still.

I also think I'm going to ignore ANY bug which has the name TTimo posted
in it... ;p

(For the humor impaired, that last part was a joke pointing back to the
entire licensing fiasco, which really did not exist since TTimo is not
actually an id Software employee.)

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Enemy Territory ebuild

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 343 bytes --]

On Sunday 19 October 2003 10:01, Chris Gianelloni wrote:
> At this point, I don't really know what I should do.  Should I simply
> leave things how they are and not worry about it at all until a new
> revision of the game is released?  Should I mask the new ebuild?  Remove
> the old?

leave things as is until the delta up GLEP is done
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Enemy Territory ebuild

[Matt Thrailkill]

It seems to me that whenever I let portage pull down a kernel for me, if
it is upgrading me (like say I have vanilla-sources-2.4.21 installed and
vanilla-sources-2.4.22 came out) it'll download the appropriate patch to
get me up, but if I've got no kernel installed at all, it pulls down the
whole thing.

Thats just me watching the beginning of the emerge process casually, I'm
too lazy to sit here and try it or go read the ebuild itself.

On Sat, 2003-10-18 at 17:08, Luke-Jr wrote:
> Unless I'm mistaken, the kernel ebuilds *always* download the whole thing, 
> except in cases when it is only available as a patch.
> - -- 
> Luke-Jr
> Developer, Gentoo Linux
> http://www.gentoo.org/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD8DBQE/kdYKZl/BHdU+lYMRAte4AJ456YdK9rMbCiR69KX1+JdkwqS/HQCfSXQm
> SUakVoPkoQHVaBnq9Tj/dN4=
> =V1lT
> -----END PGP SIGNATURE-----
> 
> 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Enemy Territory ebuild

[Dhruba Bandopadhyay]

<quote who="Chris Gianelloni">
> I want to ask the opinion of everyone.  I updated Enemy-Territory
> yesterday to close two bugs.  In doing so, I made the decision to make
> the newest version of Enemy Territory use the new full download.  I have
> had requests from people to have the full download, rather than the
> original download + patches, as the ebuild.

Few alternative suggestions:

(1) Have use flag 'patchpkg' or 'patch'.  If enabled patch the package
otherwise download.  This is a long term solution that could be used by
other packages too (although I hear you wish to avoid use flags).

(2) Check what files present in distfiles.  The user should fetch patch
manually into distfiles to enable patching.

  (2) (a) If only patch file present the ebuild opts for patching.

  (2) (b) If only full new download present ebuild uses it.

  (2) (c) If both present ebuild uses full download.

(3) Use an environment variable like USE_PATCH="yes".  They are more
environmentally friendly given the late explosion in number of use flags
making them unmanageable and resulting in information overload.

Adding to the thought pool.  Take from it what you will.  :)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Enemy Territory ebuild

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2869 bytes --]

Well, I am simply going to leave it as full versions for the time
being.  I apologise to dial-up users, but I believe something like this
should follow the policies that will be implemented with GLEP #9.

I would definitely *not* use a USE flags at all, since a USE flag is for
adding or removing optional features from a package.  If anything were
to be used, it would be a FEATURE flag.

Having the user manually fetching patches would break the
non-interactivity of portage.  Yes, I know the ebuld already does this
in a way, but I'm speaking from a general perspective on packages, not
just specific to this one.

An environment variable would be a way to implement the patching, but
would not work with portage, since the SRC_URI would still force the
download of both the full version and the patches.

The only way to keep the portage frmo downloading all the files is via a
USE flag, which I find to be a bad implementation decision for this
particular problem.  Quite honestly, I see all game ebuilds of this type
using patches in the future.  The big problem as I see it is I have had
quite a number of complaints from people BECAUSE I was using the
patches.  They were "annoyed" by the fact that a certain ebuild would
every download the files from a previous version.  Quite honestly, I
should have simply closed the bug as WONTFIX and left everything as it
was with patches.

On Tue, 2003-10-21 at 08:39, Dhruba Bandopadhyay wrote:
> <quote who="Chris Gianelloni">
> > I want to ask the opinion of everyone.  I updated Enemy-Territory
> > yesterday to close two bugs.  In doing so, I made the decision to make
> > the newest version of Enemy Territory use the new full download.  I have
> > had requests from people to have the full download, rather than the
> > original download + patches, as the ebuild.
> 
> Few alternative suggestions:
> 
> (1) Have use flag 'patchpkg' or 'patch'.  If enabled patch the package
> otherwise download.  This is a long term solution that could be used by
> other packages too (although I hear you wish to avoid use flags).
> 
> (2) Check what files present in distfiles.  The user should fetch patch
> manually into distfiles to enable patching.
> 
>   (2) (a) If only patch file present the ebuild opts for patching.
> 
>   (2) (b) If only full new download present ebuild uses it.
> 
>   (2) (c) If both present ebuild uses full download.
> 
> (3) Use an environment variable like USE_PATCH="yes".  They are more
> environmentally friendly given the late explosion in number of use flags
> making them unmanageable and resulting in information overload.
> 
> Adding to the thought pool.  Take from it what you will.  :)
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
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 --]

[gentoo-dev] Re: Use of USE flags..? Was: Re: [gentoo-dev] Enemy Territory ebuild

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2741 bytes --]

On Tue, 2003-10-21 at 13:39, Stroller wrote:
> On Oct 21, 2003, at 2:15 pm, Chris Gianelloni wrote:
> >
> > I would definitely *not* use a USE flags at all, since a USE flag is 
> > for
> > adding or removing optional features from a package.  If anything were
> > to be used, it would be a FEATURE flag.
> 
> I am aware of the -devs attitude towards USE-flag bloat, and my 
> original posting "you can never have too many USE flags" was intended 
> as a joke (obviously a very poor one). However, from a user perspective 
> USE flags are quite desirable - they keep all options in one place, I 
> can `emerge -vp someapp` & easily use `ufed` to determine what each 
> flag means & change it as required.

However, a USE flag has a specific function and should stay that way to
keep confusion down.  There are already a few cases where USE flags are
used to do things they shouldn't be.

> You say that "a USE flag is for adding or removing optional features 
> from a package", however I am not really clear what this means. My 
> recent experimentation, for instance, with the prelinking & the "pic" 
> USE flag seems to indicate that "-fPIC" will be added to the user's 
> CFLAGS. But only, I think, if the package supports prelinking..?

The -fPIC is actually used to enable PIC support in applications.  For
example, if you were to have -fPIC in your CFLAGS, there are some
packages that will NOT compile.  The pic USE flag is for enabling -fPIC
in a way which is suitable to the package.  It isn't just tacking
"-fPIC" onto your CFLAGS and that's it.  In many cases it requires
patches to the source, which aren't needed when not compiling with
-fPIC.

> Having USE flags change CFLAGS seems to me to be non-intuitive, and I 
> don't really see how a "patches" USE flag is any different from the 
> existing "mmx", "oss", or (to be honest) any other USE flags.

Let's take... a fictional game I would like to call GentooRulez. 
GentooRulez can use mmx, but only if it is added on the ./configure line
with a --enable-mmx.  Otherwise, it builds without.  This is the prime
example of when to use the mmx USE flag.

Now, a new version of GentooRulez comes out and you want to merge it
using patches.  You are wanting to tell PORTAGE itself to use patches. 
It makes no changes to the actual configuration/build.  FEATURES control
portage itself.  USE flags control the package compilation/install
options.

> Could someone be so kind as to explain when a USE flag should & should 
> not be used, and what is the difference between USE flags & FEATUREs..?
> 
> Many thanks,
> 
> Stroller.
-- 
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 --]