| 1 |
Well, I am simply going to leave it as full versions for the time |
| 2 |
being. I apologise to dial-up users, but I believe something like this |
| 3 |
should follow the policies that will be implemented with GLEP #9. |
| 4 |
|
| 5 |
I would definitely *not* use a USE flags at all, since a USE flag is for |
| 6 |
adding or removing optional features from a package. If anything were |
| 7 |
to be used, it would be a FEATURE flag. |
| 8 |
|
| 9 |
Having the user manually fetching patches would break the |
| 10 |
non-interactivity of portage. Yes, I know the ebuld already does this |
| 11 |
in a way, but I'm speaking from a general perspective on packages, not |
| 12 |
just specific to this one. |
| 13 |
|
| 14 |
An environment variable would be a way to implement the patching, but |
| 15 |
would not work with portage, since the SRC_URI would still force the |
| 16 |
download of both the full version and the patches. |
| 17 |
|
| 18 |
The only way to keep the portage frmo downloading all the files is via a |
| 19 |
USE flag, which I find to be a bad implementation decision for this |
| 20 |
particular problem. Quite honestly, I see all game ebuilds of this type |
| 21 |
using patches in the future. The big problem as I see it is I have had |
| 22 |
quite a number of complaints from people BECAUSE I was using the |
| 23 |
patches. They were "annoyed" by the fact that a certain ebuild would |
| 24 |
every download the files from a previous version. Quite honestly, I |
| 25 |
should have simply closed the bug as WONTFIX and left everything as it |
| 26 |
was with patches. |
| 27 |
|
| 28 |
On Tue, 2003-10-21 at 08:39, Dhruba Bandopadhyay wrote: |
| 29 |
> <quote who="Chris Gianelloni"> |
| 30 |
> > I want to ask the opinion of everyone. I updated Enemy-Territory |
| 31 |
> > yesterday to close two bugs. In doing so, I made the decision to make |
| 32 |
> > the newest version of Enemy Territory use the new full download. I have |
| 33 |
> > had requests from people to have the full download, rather than the |
| 34 |
> > original download + patches, as the ebuild. |
| 35 |
> |
| 36 |
> Few alternative suggestions: |
| 37 |
> |
| 38 |
> (1) Have use flag 'patchpkg' or 'patch'. If enabled patch the package |
| 39 |
> otherwise download. This is a long term solution that could be used by |
| 40 |
> other packages too (although I hear you wish to avoid use flags). |
| 41 |
> |
| 42 |
> (2) Check what files present in distfiles. The user should fetch patch |
| 43 |
> manually into distfiles to enable patching. |
| 44 |
> |
| 45 |
> (2) (a) If only patch file present the ebuild opts for patching. |
| 46 |
> |
| 47 |
> (2) (b) If only full new download present ebuild uses it. |
| 48 |
> |
| 49 |
> (2) (c) If both present ebuild uses full download. |
| 50 |
> |
| 51 |
> (3) Use an environment variable like USE_PATCH="yes". They are more |
| 52 |
> environmentally friendly given the late explosion in number of use flags |
| 53 |
> making them unmanageable and resulting in information overload. |
| 54 |
> |
| 55 |
> Adding to the thought pool. Take from it what you will. :) |
| 56 |
> |
| 57 |
> -- |
| 58 |
> gentoo-dev@g.o mailing list |
| 59 |
-- |
| 60 |
Chris Gianelloni |
| 61 |
Developer, Gentoo Linux |
| 62 |
Games Team |
| 63 |
|
| 64 |
Is your power animal a pengiun? |
Archives