Summary: | [tracker] ebuilds using gtk3 or similar useflags (talk on ML) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Julian Ospald <hasufell> |
Component: | New packages | Assignee: | Julian Ospald <hasufell> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | gnome, nikoli, qa |
Priority: | Normal | Keywords: | Tracker |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=489810 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 420433, 420525, 420527, 420529, 420531, 420533, 420535, 420537, 420539, 420541, 420543, 420545, 420547, 420549, 420551, 420553, 420555, 420557, 420559, 420561, 420563, 420565, 420567, 420569, 431828, 497144 | ||
Bug Blocks: |
Description
Julian Ospald
2012-06-10 14:18:25 UTC
You really have not addressed all the situations here. Say I have package app-misc/foo-2.4.9, it supports GTK 2 or 3 based on a configure switch. It supports a Firefox plugin when built with GTK 2 but not hen built with 3. The 3 proposed solutions don't provide for a reasonable way for users to install the package since portage will show the highest slot when they emerge. Now app-misc/foo-2.4.9 depends on dev-libs/foo-2.4.9, which can be built with GTK 2 or 3. Based on the proposed suggestions, we would skip GTK 3 support which now means Gentoo users couldn't get full support from app-misc/foo. Or creating 2 SLOTs requiring the maintainer of dev-libs/foo to maintain 2 versions of the same package that differ by 2 bytes. (2 -> 3 in the SLOT variable and the ./configure script) Another solution would be to require each package that installs libraries to double compile to install the GTK 2 and 3 versions. Which is exactly the situation we have now for several packages using the gtk3 use flag to enable the double compile. You really should bring this up on the gentoo-dev ML for more discussion. (In reply to comment #1) > You really have not addressed all the situations here. Say I have package > app-misc/foo-2.4.9, it supports GTK 2 or 3 based on a configure switch. It > supports a Firefox plugin when built with GTK 2 but not hen built with 3. > The 3 proposed solutions don't provide for a reasonable way for users to > install the package since portage will show the highest slot when they > emerge. > > Now app-misc/foo-2.4.9 depends on dev-libs/foo-2.4.9, which can be built > with GTK 2 or 3. Based on the proposed suggestions, we would skip GTK 3 > support which now means Gentoo users couldn't get full support from > app-misc/foo. Or creating 2 SLOTs requiring the maintainer of dev-libs/foo > to maintain 2 versions of the same package that differ by 2 bytes. (2 -> 3 > in the SLOT variable and the ./configure script) > > Another solution would be to require each package that installs libraries to > double compile to install the GTK 2 and 3 versions. Which is exactly the > situation we have now for several packages using the gtk3 use flag to enable > the double compile. Thanks for the addition. Yes I know there may be situations where the proposed solutions are not sufficient. That is dicussed in the bugs then. But I wanted to have an overview of the situation since the gtk useflag was not meant to be slot-specific in the first place. Other solutions may be valid, but are still a migration issue, so I add them here. > > You really should bring this up on the gentoo-dev ML for more discussion. It was already before I opened this bug. I really don't know why you open this issue while the situation was clearly explained by the gnome team a couple of times already. All gnome maintained ebuilds already follow the policy with care to still allow relatively easy maintenance, so what exactly do you expect ? (In reply to comment #3) > I really don't know why you open this issue while the situation was clearly > explained by the gnome team a couple of times already. > > All gnome maintained ebuilds already follow the policy with care to still > allow relatively easy maintenance, so what exactly do you expect ? This is a tracker and used for tracking possible misuse of gtk3 useflag, discussion is on the ML. You may ignore this or mark my bugs assigned to you (if there is one) as INVALID/WONTFIX if the rationale does not apply or if you disagree with it. I cannot make any sense out of the council log and the gnome team didn't tell me anything that will help me here, so closed as WORKSFORME. I don't have the time to hunt for answers all day long. It is ongoing. (In reply to Tom Wijsman (TomWij) from comment #6) > It is ongoing. Good luck then, please open a new tracker if you need one, I don't want to get any mails about this. |