<Resend after subscribe>
Duncan wrote:
> For kde-4.11, it seems the gentoo/kde project has decided to hard-enable
> the former semantic-desktop USE flag, forcing the option on and forcing a
> number of formerly optional additional dependencies.[1]
>
> But, I spent quite some time here switching away from kdepim's kmail,
> akregator, etc, so I could kill akonadi on my system, and with it
> semantic-desktop, etc, and I'm in no mood to have it hard-enabled now.
> If it comes to it, I'd rather dump the kde desktop and switch to something
> else[2], than have semantic-desktop on my system once again.
I *totally* concur. After finally getting rid of KMail, it took me 9 months
to work out and feel comfortable with mutt[1], and then it was much less of a
step to get rid of nubkit, as well as semantic-craptop.
Finally, at 4.9 my KDE has come back to me, and feels as slick as 3.5 :-)
That's progress for ya.. ;p
> But with a bit of luck, I won't have to switch away from kde after all.
..
> Meanwhile, as I upgraded to the kde-4.11 pre-releases (currently 4.10.90
> aka 4.11-beta2) in the kde overlay, for the kde-desktop-core and other
> gentoo/kde packages I still run, I diffed the ebuilds between 4.10.x and
> 4.10.80 (aka 4.11-beta1), then checked the diffs for non-semantic-desktop
> related changes and kept them, while changing the semantic-desktop force-
> enabling changes to force-disabling instead.
>
> Then I created a framework that works much like epatch_user, except
> instead of automatically applying patches to upstream sources, it
> automatically applies patches to gentoo ebuilds and instead of using the
> /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.
Hmm that's quite interesting. Not something I'd personally want in the tree,
but definitely of interest to more advanced admins, as opposed to end-users.
(Yeah, we're all admins. Still, I don't administer a large network, and I
don't call myself a sys-admin. I just appreciate good infra.)
> So now I have a set of ebuild patches that patch the kde 4.11 ebuilds
> (starting with 4.10.80, aka 4.11-beta1) to force-disable semantic-
> desktop, instead of force-enabling it. And I have a scripted framework
> that auto-applies these patches to new ebuilds on emerge --sync and layman
> -S, thus keeping no-semantic around as upstream gentoo/kde updates their
> ebuilds.
Have to say I think I'd prefer this as a semi-automatically generated overlay.
ie apply the patches, and if they work, let the maintainer confirm after
testing.
> For now, therefore, I'm fine, up and running on 4.10.90 (aka 4.11-beta2),
> using gentoo/kde ebuilds auto-patched to kill the now forced-on semantic-
> desktop, forcing it off instead.
>
> But realistically, I honestly don't know if longer term, I'll be able to
> continue maintenance of all of this by myself. Chances are unfortunately
> high that without help from others, over time I'll decide it's simply too
> much of a hassle maintaining the patches
Indeed. You shouldn't be doing this alone, over the longer-term: it'll just
burn you out.
> Besides which, if I'm finding kde-nosemantic useful enough to go to all
> this trouble, there's a good chance that others will be interested in it
> themselves, especially if they don't have to do all the work I'm now doing
> myself, themselves. So with kde-sunset in mind as precedent, I'm now
> proposing a kde-nosemantic overlay, like kde-sunset, user-maintained, but
> for kde4 folks who want a continued no-semantic choice, instead of kde3
> users.
>
> Any interest?
Hell yeah :-)[2] You picked an odd forum for it though: I only found out about
this because Dominique posted to pro-audio list.
> To be further discussed: Assuming a go-ahead on the general idea, do we
> want to maintain it as a normal overlay carrying at least the kde4 ebuilds
> that require patching to kill semantic-desktop
Yes, as above. I much prefer the traceability of an overlay with conventional
ebuilds in it. If we're going to do this, let's do it right.
> or should we simply build
> on the epatch_ebuild_user scripts I have hacked up, presumably checking
> them into a git repo along with the patches themselves somewhere and
> making that available
..
> One bonus to the tools overlay instead of a direct kde-nosemantic overlay
> approach, is that gentooers not interested in kde, but interested in the
> ebuild-patch tools, might find that useful, add that overlay to their
> layman overlay list, and contribute patches to the ebuild-patches tool,
> helping it mature and grow into a general purpose automated-ebuild-
> patching tool rather faster than it might otherwise happen.
Yes, the tools should be available in their own right.
Tho that was an awfully long-winded way of saying "Ebuild-patch tools could
well be of wider interest." ;)
> A hybrid alternative would be to adopt an idea much like the existing kde
> overlay, where there's a documentation or tools directory that carries
> them, in addition to the kde-base category and etc, carrying the patched
> ebuilds themselves.
That sounds ideal, but why not just have two overlays? One for ebuild-patch
which others can use and collaborate around, and one conventional kde-lean
for people who want the end-product.
After all, ebuild-patch tools are strictly for maintainers, and people who
want to experiment on their system. The output ebuilds have an orthogonal use.
I'd ask that we collaborate on the forums[2] about this: things can move much
quicker there, and you get general encouragement and lots of bug feedback,
as well as others to help.
creaker patched kdelibs, as you'll see, already, and he's interested in
working on the overlay ("Without overlay it may be boring to do the things
I did before on every update.") So between the two of you, and as others
get involved, I'm sure it can be done. As you said, KDE-4 is practically
EOL, given that more developer focus is on 5.
I can get the overlays, git and trac setup, same as we did for hardened a few
years ago, if that helps.
Regards,
steveL.
[1] Kmail to mutt with Maildir and procmail:
http://forums.gentoo.org/viewtopic-t-945868.html
[2] How to opt out of a semantic-desktop?
http://forums.gentoo.org/viewtopic-t-963504.html
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Duncan wrote:
> For kde-4.11, it seems the gentoo/kde project has decided to hard-enable
> the former semantic-desktop USE flag, forcing the option on and forcing a
> number of formerly optional additional dependencies.[1]
>
> But, I spent quite some time here switching away from kdepim's kmail,
> akregator, etc, so I could kill akonadi on my system, and with it
> semantic-desktop, etc, and I'm in no mood to have it hard-enabled now.
> If it comes to it, I'd rather dump the kde desktop and switch to something
> else[2], than have semantic-desktop on my system once again.
I *totally* concur. After finally getting rid of KMail, it took me 9 months
to work out and feel comfortable with mutt[1], and then it was much less of a
step to get rid of nubkit, as well as semantic-craptop.
Finally, at 4.9 my KDE has come back to me, and feels as slick as 3.5 :-)
That's progress for ya.. ;p
> But with a bit of luck, I won't have to switch away from kde after all.
..
> Meanwhile, as I upgraded to the kde-4.11 pre-releases (currently 4.10.90
> aka 4.11-beta2) in the kde overlay, for the kde-desktop-core and other
> gentoo/kde packages I still run, I diffed the ebuilds between 4.10.x and
> 4.10.80 (aka 4.11-beta1), then checked the diffs for non-semantic-desktop
> related changes and kept them, while changing the semantic-desktop force-
> enabling changes to force-disabling instead.
>
> Then I created a framework that works much like epatch_user, except
> instead of automatically applying patches to upstream sources, it
> automatically applies patches to gentoo ebuilds and instead of using the
> /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.
Hmm that's quite interesting. Not something I'd personally want in the tree,
but definitely of interest to more advanced admins, as opposed to end-users.
(Yeah, we're all admins. Still, I don't administer a large network, and I
don't call myself a sys-admin. I just appreciate good infra.)
> So now I have a set of ebuild patches that patch the kde 4.11 ebuilds
> (starting with 4.10.80, aka 4.11-beta1) to force-disable semantic-
> desktop, instead of force-enabling it. And I have a scripted framework
> that auto-applies these patches to new ebuilds on emerge --sync and layman
> -S, thus keeping no-semantic around as upstream gentoo/kde updates their
> ebuilds.
Have to say I think I'd prefer this as a semi-automatically generated overlay.
ie apply the patches, and if they work, let the maintainer confirm after
testing.
> For now, therefore, I'm fine, up and running on 4.10.90 (aka 4.11-beta2),
> using gentoo/kde ebuilds auto-patched to kill the now forced-on semantic-
> desktop, forcing it off instead.
>
> But realistically, I honestly don't know if longer term, I'll be able to
> continue maintenance of all of this by myself. Chances are unfortunately
> high that without help from others, over time I'll decide it's simply too
> much of a hassle maintaining the patches
Indeed. You shouldn't be doing this alone, over the longer-term: it'll just
burn you out.
> Besides which, if I'm finding kde-nosemantic useful enough to go to all
> this trouble, there's a good chance that others will be interested in it
> themselves, especially if they don't have to do all the work I'm now doing
> myself, themselves. So with kde-sunset in mind as precedent, I'm now
> proposing a kde-nosemantic overlay, like kde-sunset, user-maintained, but
> for kde4 folks who want a continued no-semantic choice, instead of kde3
> users.
>
> Any interest?
Hell yeah :-)[2] You picked an odd forum for it though: I only found out about
this because Dominique posted to pro-audio list.
> To be further discussed: Assuming a go-ahead on the general idea, do we
> want to maintain it as a normal overlay carrying at least the kde4 ebuilds
> that require patching to kill semantic-desktop
Yes, as above. I much prefer the traceability of an overlay with conventional
ebuilds in it. If we're going to do this, let's do it right.
> or should we simply build
> on the epatch_ebuild_user scripts I have hacked up, presumably checking
> them into a git repo along with the patches themselves somewhere and
> making that available
..
> One bonus to the tools overlay instead of a direct kde-nosemantic overlay
> approach, is that gentooers not interested in kde, but interested in the
> ebuild-patch tools, might find that useful, add that overlay to their
> layman overlay list, and contribute patches to the ebuild-patches tool,
> helping it mature and grow into a general purpose automated-ebuild-
> patching tool rather faster than it might otherwise happen.
Yes, the tools should be available in their own right.
Tho that was an awfully long-winded way of saying "Ebuild-patch tools could
well be of wider interest." ;)
> A hybrid alternative would be to adopt an idea much like the existing kde
> overlay, where there's a documentation or tools directory that carries
> them, in addition to the kde-base category and etc, carrying the patched
> ebuilds themselves.
That sounds ideal, but why not just have two overlays? One for ebuild-patch
which others can use and collaborate around, and one conventional kde-lean
for people who want the end-product.
After all, ebuild-patch tools are strictly for maintainers, and people who
want to experiment on their system. The output ebuilds have an orthogonal use.
I'd ask that we collaborate on the forums[2] about this: things can move much
quicker there, and you get general encouragement and lots of bug feedback,
as well as others to help.
creaker patched kdelibs, as you'll see, already, and he's interested in
working on the overlay ("Without overlay it may be boring to do the things
I did before on every update.") So between the two of you, and as others
get involved, I'm sure it can be done. As you said, KDE-4 is practically
EOL, given that more developer focus is on 5.
I can get the overlays, git and trac setup, same as we did for hardened a few
years ago, if that helps.
Regards,
steveL.
[1] Kmail to mutt with Maildir and procmail:
http://forums.gentoo.org/viewtopic-t-945868.html
[2] How to opt out of a semantic-desktop?
http://forums.gentoo.org/viewtopic-t-963504.html
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)