| 1 |
Jorge Manuel B. S. Vicetto wrote: |
| 2 |
|
| 3 |
> The next step was to use a kdeprefix use flag[2]. This flag no longer |
| 4 |
> touches the SLOT that is set to "4" for all kde-4.X versions. It only |
| 5 |
> determines if the package will be installed under the FHS compliant |
| 6 |
> location (/usr) or under the old location (/usr/kde/<version>). This |
| 7 |
> however means the users will no longer have the option to have more than |
| 8 |
> one kde-4.X version installed. |
| 9 |
If that stops _all_ users from doing so, I'd vote against. |
| 10 |
|
| 11 |
> I've been thinking on a different method. With this method [3], we would |
| 12 |
> keep using the <major>.<minor> slots (4.1, 4.2, etc) so we also wouldn't |
| 13 |
> break the invariancy. We would allow users to select whether to have an |
| 14 |
> FHS compliant install or not (the way to allow that still needs to be |
| 15 |
> discussed) and we would set the prefix based on that. In case the user |
| 16 |
> wants an FHS compliant install, the eclasses would block all kde |
| 17 |
> packages on other slots - except 3.5 (uses other eclasses) and the live |
| 18 |
> versions (for the above reason that it will always be installed under |
| 19 |
> /usr/kde/<live-version>). One way to decide whether to install on an FHS |
| 20 |
> compliant location would be to add a use flag, but I don't think adding |
| 21 |
> that flag for 200+ ebuilds makes sense as it doesn't make sense to have |
| 22 |
> 1 version of some packages and possibly 2 or more of other packages. |
| 23 |
> |
| 24 |
Perhaps FHS is more of a feature than a USE flag? It certainly could apply |
| 25 |
to other packages, and as you say adding and maintaining the USE flag |
| 26 |
to/for so many ebuilds is a bit of a pain. |
| 27 |
|
| 28 |
> So, what am I after in this email? After having an internal discussion |
| 29 |
> and then opening it up to users in #gentoo-kde and a few other people on |
| 30 |
> #gentoo-portage, it was suggested I sent a mail here to open this |
| 31 |
> discussion to everyone and to present the case in a more clear manner. |
| 32 |
> So, can anyone suggest a good way to accomplish what were trying to do? |
| 33 |
> At least a better solution than the ones I've presented above? |
| 34 |
|
| 35 |
Just a thought, but this sounds an awful lot like a prefix ebuild. Is there |
| 36 |
any relevance from grobian's work? |
| 37 |
|
| 38 |
Wrt to the blocks, it doesn't strike me that major iff the user has set FHS |
| 39 |
in FEATURES (or w/e the mechanism is) since in that case they will be on |
| 40 |
the "manage everything for me, for this install" track. |
Archives