| 1 |
* Noack, Sebastian <S.Noack@××××××××××.de> schrieb: |
| 2 |
|
| 3 |
<snip> |
| 4 |
|
| 5 |
> Is a need to have dozens of lines in your /etc/portage/package.use |
| 6 |
> a simple approach? Maybe it is, if for you, simplicity means only |
| 7 |
> "less number of lines of code in the core of the application". |
| 8 |
> But wasn't you the one who told me that quantity isn't the same like |
| 9 |
> complexity? Well you could say that only source code and scripts |
| 10 |
> contain logic and therefore numbers of lines in the config files |
| 11 |
> doesn't means complexity, but what do I do by the config files of |
| 12 |
> portage actually? I use them for example to instruct portage to |
| 13 |
> enable useflag A but not for ebuild and useflag B but just for |
| 14 |
> ebuild b. Do you claim that this is no logic? |
| 15 |
|
| 16 |
No, that's just quantity of information. Linear data, just like an |
| 17 |
list of addresses or phone numbers. There are no rules in it. |
| 18 |
|
| 19 |
The rules just exist in your mind, not in the portage system. |
| 20 |
And if you like to modelize them, it should be done separately |
| 21 |
on top of portage. |
| 22 |
|
| 23 |
Okay, let's assume for a while, we've got your additional rules |
| 24 |
in the portage system. Someone has to make the decision about |
| 25 |
which frontends to prefer over others. If it's you, then you'll |
| 26 |
be happy with that, since you'll most likely decide the way you |
| 27 |
like, but others may be very unhappy with your decisions. On the |
| 28 |
other hand, with anyone else making this decision, there's plenty |
| 29 |
risk, you'll be unhappy with his decision. |
| 30 |
|
| 31 |
I see big flamewars coming on that. |
| 32 |
Remember the sunrise affair(s) ? |
| 33 |
|
| 34 |
<snip> |
| 35 |
|
| 36 |
> > Rember: we started with the thesis, "grandma wants graphical |
| 37 |
> > frontends whereever possible". This is in fact not an technical |
| 38 |
> > issue, instead a matter of personal taste, or lets say, an individual |
| 39 |
> > system configuration. Grandma wants to click, okay, so she should |
| 40 |
> > use graphical applications. She's not interested what sits behind, |
| 41 |
> > she just wants to have a buch of applications. And she also doesn't |
| 42 |
> > wann have anything to do with emerge and useflags. She just wants |
| 43 |
> > to have a choice between a bunch of end-user applications. |
| 44 |
> > That's the job of an Grandma-(sub-)distro. |
| 45 |
> |
| 46 |
> That was never the point where "we" started. That was just the point, |
| 47 |
> you used to confuse this discussion. |
| 48 |
|
| 49 |
Maybe I missed something, but this was the first posting I read on |
| 50 |
that topic. |
| 51 |
|
| 52 |
> The grandma scenario should just be a funny example for a requirement |
| 53 |
> of such a advanced portage syntax I could really need on my own systems |
| 54 |
> and I'm not female, but male and not 80 but 18 years old. ;) |
| 55 |
|
| 56 |
IMHO an bad chosen one, as I take such examples seriously. |
| 57 |
|
| 58 |
<snip> |
| 59 |
|
| 60 |
> I know that my proposed syntax isn't a perfect solution. But I think the |
| 61 |
> current state of portage isn't a perfect solution, too. And I hoped when |
| 62 |
> I started this thread, that we will find together a good solution. |
| 63 |
|
| 64 |
IMHO, the problem isn't yet defined cleanly enough to have a chance |
| 65 |
on an good solution. |
| 66 |
|
| 67 |
|
| 68 |
cu |
| 69 |
-- |
| 70 |
--------------------------------------------------------------------- |
| 71 |
Enrico Weigelt == metux IT service - http://www.metux.de/ |
| 72 |
--------------------------------------------------------------------- |
| 73 |
Please visit the OpenSource QM Taskforce: |
| 74 |
http://wiki.metux.de/public/OpenSource_QM_Taskforce |
| 75 |
Patches / Fixes for a lot dozens of packages in dozens of versions: |
| 76 |
http://patches.metux.de/ |
| 77 |
--------------------------------------------------------------------- |
| 78 |
-- |
| 79 |
gentoo-dev@g.o mailing list |
Archives