| 1 |
On November 12, 2008, Volker Armin Hemmann wrote: |
| 2 |
> > wouldn't call it stupid though. FHS compliance is a good thing (I'm a |
| 3 |
> > sysadmin so I really appreciate when things can be easily located |
| 4 |
> > universaly). |
| 5 |
> |
| 6 |
> why? the FHS is a stupid standard. Why is following stupid standards a good |
| 7 |
> thing? What next? LSB compliance - because it is great to be broken by |
| 8 |
> definition? |
| 9 |
|
| 10 |
any consistency on a system is a good thing. when you deal with N systems you |
| 11 |
really appreciate when things are easily located and could be deducted easily |
| 12 |
even if you don't know where they are. Any standard could easily be |
| 13 |
called "stupid" but in absense of better alternatives I'd rather |
| 14 |
have "stupid" standard than none. |
| 15 |
|
| 16 |
> > I think what failed is communication on that change. In |
| 17 |
> > developers defense I'd say that we're dealing with ~arch packages here so |
| 18 |
> > we've been warned they'll be somewhat not-so-stable. What I think needs |
| 19 |
> > to happen is gentoo users have to be warned in big red letters everywhere |
| 20 |
> > possible when upgrading from KDE3 to KDE4 to make firm decision whether |
| 21 |
> > to use "kdeprefix" or not. |
| 22 |
> |
| 23 |
> it would have been better to NOT introduce that kdeprefix flag and instead |
| 24 |
> introducing a FHS flag - which should have been off by default. The current |
| 25 |
> way - kdeprefix to get sane behaviour, that turned off, changing the |
| 26 |
> default behaviour is either stupid or evil. |
| 27 |
|
| 28 |
see, that depends on your perspective and long term goal. Like Alan mentioned |
| 29 |
in his post: if long-term strategy is to have gentoo more FHS-friendly (for |
| 30 |
whatever reasons) then default compliance is a good thing, if long-term |
| 31 |
solution is to keep doing things in non-FHS-way (a.k.a. gentoo-way ;) ) then |
| 32 |
your suggestion is a more viable one. So the real question you want to |
| 33 |
ask: "Is gentoo as a whole intends to be FHS compliant in the future? What |
| 34 |
are the reasons for that? Can I opt-out?". For myself I think I know answers |
| 35 |
for the last two, but for you, I guess you'd have to find out yourself. What |
| 36 |
would be interesting to know for the entire group is the answer to the first |
| 37 |
question: "Is gentoo as a whole intends to be FHS compliant in the future?". |
| 38 |
Does anybody know the answer? |
| 39 |
|
| 40 |
> > Enforcing proper FS layout is a good thing IMO. Just needs clear |
| 41 |
> > communication before marked as stable :) |
| 42 |
> |
| 43 |
> Like making kde update interactive? Require a 'yes, I know about kdeprefix' |
| 44 |
> dialog box? |
| 45 |
|
| 46 |
no. there are simplier alternatives. Read Alan's post, and as an alternative |
| 47 |
here's my take: you can fail building any kde build if state of "kdeprefix" |
| 48 |
is undefined in /etc/make.conf. So you'd have to have that either explicitely |
| 49 |
enable or disable there. Not sure if that'd be easy to implement with current |
| 50 |
portage EAPI (not flaming - just don't know ;) ) |
| 51 |
|
| 52 |
> kde has always been in its own directory tree. /opt back in the suse days |
| 53 |
> for example. Elderly kde documentation told people to install kde in its |
| 54 |
> own sub tree - and I loved that. I always hated gnome for cluttering /usr |
| 55 |
> with its garbage. Having a big project like kde in its own tree has a |
| 56 |
> bazillion of advantages. |
| 57 |
|
| 58 |
I can list quite a few disadvantages as well. So it boils down to the matter |
| 59 |
of personal preference and the direction that gentoo dev team chose for the |
| 60 |
future. |
| 61 |
|
| 62 |
-- |
| 63 |
Dmitry Makovey |
| 64 |
Web Systems Administrator |
| 65 |
Athabasca University |
| 66 |
(780) 675-6245 |
Archives