| 1 |
> On Mon, 2005-08-29 at 20:10 +0200, Patrick Lauer wrote: |
| 2 |
>> On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote: |
| 3 |
>> > As I understood it, they were implemented to reduce the amount of work |
| 4 |
>> > necessary in maintaining them. As it was back then, it required |
| 5 |
>> changes |
| 6 |
>> > to an extremely large number of profiles every time a change was made |
| 7 |
>> to |
| 8 |
>> > the default USE flags. |
| 9 |
> |
| 10 |
>> Just a crazy idea - why not create a package containing some profiles? |
| 11 |
>> You can use the default profile, and if you want a different profile, |
| 12 |
>> "emerge portage-profiles" or whatever it is called and use that. I guess |
| 13 |
>> I've missed something obvious here? |
| 14 |
> |
| 15 |
> How exactly would updating a ton of profiles, making a tarball of them, |
| 16 |
> uploading the new tarball, waiting for it to hit the mirrors, then |
| 17 |
> updating the ebuild in portage be easier to maintain than just |
| 18 |
> maintaining the profiles directly in the tree? |
| 19 |
> |
| 20 |
>> > I honestly don't think it would be a good idea |
| 21 |
>> > to forget the lessons of the past and start bloating the profiles with |
| 22 |
>> > tons of "desktop" and "server" profiles, among anything else people |
| 23 |
>> > would want. After all, as soon as we did a "desktop" profile, then we |
| 24 |
>> > would have requests for "gnome" and "kde" sub-profiles. |
| 25 |
> |
| 26 |
>> which are not much work if kde = desktop -gtk -gnome +kde |
| 27 |
> |
| 28 |
> Once there is multiple inheritance, I see this being easier. I still |
| 29 |
> think it is going to be a waste of time for us to maintain them, |
| 30 |
> however. Especially since *NO MEDIA* will be built against *any* of |
| 31 |
> them except the default. |
| 32 |
> |
| 33 |
>> > As I stated earlier, it's easier to not provide *any* than to try to |
| 34 |
>> > provide all of the ones that will inevitably be requested as soon as |
| 35 |
>> we |
| 36 |
>> > start adding them. |
| 37 |
>> Or provide them in an extra ebuild that throws lots of warnings so that |
| 38 |
>> any users that don't read the warnings can be RESOLVED WONTFIXed? |
| 39 |
> |
| 40 |
> You're more than welcome to do this. *I* would just WONTFIX it anyway |
| 41 |
> and not add *any* superfluous profiles just to appease some lazy users. |
| 42 |
> The current profiles are built to be used *as is* for doing GRP |
| 43 |
> installations. If the user doesn't like a flag or two, then they change |
| 44 |
> it themselves. We don't need to get into the business of determining |
| 45 |
> what should and should not be enabled on user's systems because we would |
| 46 |
> *never* be able to make people happy. |
| 47 |
> |
| 48 |
I think Brian mentioned /etc/portage/profile and other fun portage tricks |
| 49 |
to mess with the default profile. If you think the profile shouldn't be |
| 50 |
changed then don't make it a mutable option. If you think that bugs |
| 51 |
where people fubared their profile are a problem then write a tool to |
| 52 |
print out that information and have the user present it to you when they |
| 53 |
file the bug. |
| 54 |
|
| 55 |
As far as maintainability, you could always make a profile outside of the |
| 56 |
default-linux tree ( default-gentoo/* ) and construct the |
| 57 |
smaller/faster/better profiles there. That means anyone that wants to |
| 58 |
customize can change the symlink and you ( releng ) still get your |
| 59 |
pristine release profiles ( which IMHO is a silly notion, but I don't |
| 60 |
manage your bugs, so whichever way you like ;) ). Going on that notion, |
| 61 |
you could also do default-linux/x86/2005.1/release or whatnot if you want |
| 62 |
to maintain that as well. |
| 63 |
|
| 64 |
-- |
| 65 |
gentoo-dev@g.o mailing list |
Archives