Bug 85476 – KDE monolithic ebuilds - I need them in my life!

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description illuminata 2005-03-16 01:48:08 UTC]

Well, as you can guess by the summary, I like my monolithics. Now, I'm not saying to bail on the metas, they definitely have their own advantages, but I'm just gonna spell out why I don't think you should ditch the old school method. So here I am, voicing my support like the split ebuilds howto said I should. At the very least, hopefully you'll find a reason in here different from the ones you've heard before.

1. Monolithics keep --pretend nice and pretty. I'm a KDE user that likes to have it all, so if I have a bunch of ebuilds wanting upgrades at the same time, the --pretend listing is gonna get ugly fast. This could easily apply to those who'd like just some of what KDE has to offer as well. I've made a suggestion for a way that emerge can tidy up listings under a meta package under bug #84617. There you'll see that ferringb also pointed out spb's GLEP. I'd at least wait for one of those two things to happen before forcing meta ebuilds on everybody.

2. I noticed how you guys are considering split tarballs, and I can definitely see how split tarballs are nice for those just wanting a few KDE packages and those on dialup. However, for those wanting to install a decent sized chunk of KDE at once (like when a new release is out), all it will take is one digest mismatch to halt the emerge. And with as many separate tarballs that we'd have, there's a good possibility that this scenario could play out. Seems to me like there's not much room for error and things would be a lot harder to manage. Not saying that you necessarily need to ditch the split tarballs however, I just wouldn't mind to have the fatties around too.

3. And, if you do go through with the split tarballs, you also have to worry about all of them hitting the mirrors, too. I've had quite a few occasions where an ebuild needed a tarball and it just wasn't there. Only in your case, you can be putting a big wrench in an emerge. And, I'm also going to have a hard time finding missing split tarballs from sources outside of Gentoo. 

4. To unmask hard-masked KDE ebuilds I now have to add a lot more lines to package.unmask. I'll also end up running into brand new KDE packages that need unmasking down the line as well, resulting in more lines I'll have to add.

5. Rather than typing out these complaints, I'll just refer you to sections of the split ebuilds howto since they're summed up pretty well for me there. So, check out "How can I unmerge an older KDE?" and "How can I list/unmerge all split ebuilds derived from a given package?". Those methods don't seem like much fun when it's easy with monolithics. And I'll also toss in "Aren't you putting too big a load on the Gentoo KDE maintainers?" even though it doesn't pertain to me much but I can see how it'd be a factor. If they do end up getting stressed out too much then us KDE users will be feeling it too.

So, there you have it. I really think that my grievances are substantial enough to warrant keeping the old way around. So, I'll be trying to fetch some people who feel the same way to voice their support here. I'm all ears for any other potential solutions as well.

By the way, wouldn't one possible solution be to recruit some more KDE devs? Seems to me like there's always around 1-4 new devs added each week according to the newsletter. If you were to grab some extra peeps for yourselves, maybe you could make both ways available? Then, you'd be operating more like Burger King!

[Comment 1 Carsten Lohrke (RETIRED) 2005-03-16 10:51:22 UTC]

Monolithic ebuilds are there at least for 3.4, maybe 3.5. Even more devs won't make it likely to support both attempts in the long run. There are better things to do. 

*** This bug has been marked as a duplicate of 81065 ***

[Comment 2 Dan Armak (RETIRED) 2005-03-19 10:29:09 UTC]

Replying to things specific to this request:
Split tarballs: just an idea. If and when we start using them, we'll address
these problems. It's not at all final that we'll use them at some point... 
They're just an idea among many.
Unmasking many packages at once: just copy the lines that mask them from
package.mask to package.unmask verbatim.