http://bugs.gentoo.org/show_bug.cgi?id=82451
------- Additional Comments From [email protected] 2005-02-18 06:29 PST -------
>The first of the two FAQ items (how to unmerge an older KDE) should indeed be
>handled by portage functionality. Specifically, GLEP 21 (package sets). meta
>ebuilds should be replaced by sets.
Exactly. I just wanted to point out the FAQ just gives a tip to solve "quickly" this issue, without giving a real answer : all older KDE apps belong to a same SLOT. But giving this bash script, the doc lets the user believe there won't be any other solution. I don't want to believe it's the case.
>(about GLEP 21...)[they] are a pain to uninstall manually.
Of course, and that's the problem.
>The user also has to know enough about
>ebuilds to understand the concept of unmerging a slotted ebuild version. IMHO
>that's on the same level of skill/knowledge as running the sample script given
>in the FAQ.
Running the script, yes. But, if I'm a normal gnome user, there are few chances I'll find this documentation, and therefore, this script.
I mean, using it is one thing. Finding it, and more important, when you *need* it, is an other one.
How many people don't read those documentation, that looks a bit like "dev docs" (for its title, because it's quite specific...)? A few people will do. They will rarely remember it. That's a pity, but well, for me, giving the script is not "enough" to say we've solved the problem, and good bye :)
(don't take it personal or whatever, I'm not trying to flame :p)
> Would it help if that script was packaged nicely and available
>through an ebuild? (gentoolkit? But that might require the script to have more
>general application...)
Yes, that's exactly what I thought. People use emerge. And for most of them, they never heard of the eclass functions... I have the chance to be the one who translated the devrel-handbook, now, I know a little about all of it. But what about the others ?
Giving a simple way to solve the problem, using standard apps, and documenting this new functionnality, is definitely the good way, I think.
>The second FAQ item's answer is aimed at people writing a script to begin with.
Yes, that's what I noticed :)
>Would it help to give here, also, a sample shell command that
>would output the list of ebuilds inheriting from a given parent package?
Yep. Because having those functions is one thing. Using it is a bit more complicated.
My final idea, about the first point, is we don't use the information that "all older KDE apps belong to a same SLOT".
Using the idea from the GLEP21, making one set for each SLOT available should then make the deal, if Portage has the possibility to unmerge an entire set.
I think giving a link to the GLEP21 would be interesting : this one seems quite readable, and is easy to understand, and see that in a few months, we should be able to use those sets to unmerge older KDE easily.
Am I right ?
Then, telling in the FAQ all those solutions are given as temp solutions and that in a couple of months, we should be able to give a better answer to this question, might be of some intereset.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--
[email protected] mailing list
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.