From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24296 invoked by uid 1002); 21 Oct 2003 13:12:58 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 4526 invoked from network); 21 Oct 2003 13:12:58 -0000 From: Chris Gianelloni To: gentoo-user@gentoo.org Cc: gentoo-dev@gentoo.org In-Reply-To: <4854.146.176.63.67.1066739940.squirrel@mail.codewordt.co.uk> References: <1066483836.28203.13.camel@localhost> <4854.146.176.63.67.1066739940.squirrel@mail.codewordt.co.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LbGDA+EuwOQ22lozzdEA" Message-Id: <1066742146.10428.57.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 21 Oct 2003 09:15:46 -0400 Subject: Re: [gentoo-dev] Enemy Territory ebuild X-Archives-Salt: 2aa0bda7-a2be-4bfd-bed4-0ab0f657ff3c X-Archives-Hash: 94af4e0076f048763b1850c96c54f60a --=-LbGDA+EuwOQ22lozzdEA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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: > > > 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 hav= e > > had requests from people to have the full download, rather than the > > original download + patches, as the ebuild. >=20 > Few alternative suggestions: >=20 > (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). >=20 > (2) Check what files present in distfiles. The user should fetch patch > manually into distfiles to enable patching. >=20 > (2) (a) If only patch file present the ebuild opts for patching. >=20 > (2) (b) If only full new download present ebuild uses it. >=20 > (2) (c) If both present ebuild uses full download. >=20 > (3) Use an environment variable like USE_PATCH=3D"yes". They are more > environmentally friendly given the late explosion in number of use flags > making them unmanageable and resulting in information overload. >=20 > Adding to the thought pool. Take from it what you will. :) >=20 > -- > gentoo-dev@gentoo.org mailing list --=20 Chris Gianelloni Developer, Gentoo Linux Games Team Is your power animal a pengiun? --=-LbGDA+EuwOQ22lozzdEA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/lTGCkT4lNIS36YERAoK2AKCSNN5OrR30R8Hmyvrgc0GEEFFNzACgrOTH CZqGV/PdjlfPJGK54Bx9W5U= =GXVM -----END PGP SIGNATURE----- --=-LbGDA+EuwOQ22lozzdEA--