SEO

I give up....I've been trying to find the names of the packages in portage,
that gives me the option in Konqueror to validate websites html coding via
w3c. Also, the package that can create thumbnailes and html coding, for a
filefolder with pictures.

Perhaps someone will be kind enough to post the names of these packages, or
point me to a webpage where the kde ebuilds are listed up against package
names in portage, and functionality?.

Kind regards,

Stig

--
* Registered Linux user #291266, with http://counter.li.org.*

Stig Mogensen wrote:
> I give up....I've been trying to find the names of the packages in portage,
> that gives me the option in Konqueror to validate websites html coding via
> w3c. Also, the package that can create thumbnailes and html coding, for a
> filefolder with pictures.
>
> Perhaps someone will be kind enough to post the names of these packages, or
> point me to a webpage where the kde ebuilds are listed up against package
> names in portage, and functionality?.

grep konqueror for the kde-base ebuilds gives a suggestion of

kde-base/kdeaddons-meta
kde-base/kmrml
kde-base/konq-plugins
kde-base/konqueror-akregator
kde-base/libkonq
kde-base/nsplugins


//Aho

Stig Mogensen wrote:

> I give up....I've been trying to find the names of the packages in
> portage, that gives me the option in Konqueror to validate websites
> html coding via w3c.

I'd have to guess kde-base/konq-plugins, as that contains the
conspicuously named file: /usr/kde/3.4/lib/kde3/libvalidatorsplugin.so

> Also, the package that can create thumbnailes and html coding, for a
> filefolder with pictures.

It may very well be the same package. Some of the files I have in that
package seem appropriate.

> Perhaps someone will be kind enough to post the names of these
> packages, or point me to a webpage where the kde ebuilds are listed up
> against package names in portage, and functionality?.

That sounds like a good idea, but it's not quite simple to implement.
There are a *lot* of split ebuilds. It has its benefits and its
drawbacks. Can't say I'm a big fan of them, just yet.

--
PeKaJe

Stay away from hurricanes for a while.

Peter Jensen wrote:

> There are a *lot* of split ebuilds. It has its benefits and its
> drawbacks. Can't say I'm a big fan of them, just yet.

The slower machine you have and there is a bugfixing ebuild, I bet all my
bucks you rather have a short wait than 4-6h for the package including the fix
to build.


//Aho

J.O. Aho wrote:

>> There are a *lot* of split ebuilds. It has its benefits and its
>> drawbacks. Can't say I'm a big fan of them, just yet.
>
> The slower machine you have and there is a bugfixing ebuild, I bet all
> my bucks you rather have a short wait than 4-6h for the package
> including the fix to build.

Yes, but the last time I tried it on a really slow machine, a full KDE
upgrade took approximately 50% longer than usual because of all the
extra unpacking and configuring (and full KDE upgrades aren't exactly
rare). Not to mention that every single deep upgrade takes
significantly longer to calculate because of the more complex dependency
tree. You just have to sit there and wait for portage to churn through
it all, every time. For a slow machine I would actually much prefer the
old monolithic ebuilds.

--
PeKaJe

God is not dead -- he's been busted.

Peter Jensen wrote:
> J.O. Aho wrote:
>
>>> There are a *lot* of split ebuilds. It has its benefits and its
>>> drawbacks. Can't say I'm a big fan of them, just yet.
>> The slower machine you have and there is a bugfixing ebuild, I bet all
>> my bucks you rather have a short wait than 4-6h for the package
>> including the fix to build.
>
> Yes, but the last time I tried it on a really slow machine, a full KDE
> upgrade took approximately 50% longer than usual because of all the
> extra unpacking and configuring

I agree on that it takes longer time with the initial install of kde-meta, but
upgrades do take a lot shorter time, even if the dependency is more complex
(by the way portage suxx when it comes to dependency checks).


> (and full KDE upgrades aren't exactly rare).

I a way this is a problem how Gentoo has decided to install, it must be quite
wonderful for the devel working with the KDE packages in Gentoo that they can
have 10 different versions installed at the same time, bu I doubt any normal
user has two different versions of KDE installed for more than a hour. There
are many times a minor update had been enough, if only one version would have
been placed in the same place.


> Not to mention that every single deep upgrade takes
> significantly longer to calculate because of the more complex dependency
> tree.

This is kind of marginal difference, you already have so much junk installed
that you hardly can blame KDE-meta for this, just take a look at the bloated
Gnome2 that so many Gentoo users has installed.


> You just have to sit there and wait for portage to churn through
> it all, every time. For a slow machine I would actually much prefer the
> old monolithic ebuilds.

There are many things that could make things a lot better for a slow machine,
a well working portage instead of the python engined file collection.


//Aho

J.O. Aho wrote:

>> Yes, but the last time I tried it on a really slow machine, a full
>> KDE upgrade took approximately 50% longer than usual because of all
>> the extra unpacking and configuring
>
> I agree on that it takes longer time with the initial install of
> kde-meta, but upgrades do take a lot shorter time, even if the
> dependency is more complex (by the way portage suxx when it comes to
> dependency checks).

Upgrades are not shorter in the long run, because KDE version upgrades
take *much* longer with split ebuilds. Just checked my logs, and even
on my fast machine the kdepim package takes a full hour longer to
compile with the split ebuilds (that's almost 70% additional compile
time). There would have to be a *lot* of minor individual package
upgrades in the span of a KDE version (which in my experience is around
3-4 months tops) in order for the split ebuilds to be faster.

>> (and full KDE upgrades aren't exactly rare).
>
> I a way this is a problem how Gentoo has decided to install, it must
> be quite wonderful for the devel working with the KDE packages in
> Gentoo that they can have 10 different versions installed at the same
> time, bu I doubt any normal user has two different versions of KDE
> installed for more than a hour. There are many times a minor update
> had been enough, if only one version would have been placed in the
> same place.

I don't really see how that relates to the problems of split vs
monolithic ebuilds. However, there have been times where it has been a
benefit for me to be able to have multiple KDE versions installed
simultaneously.

>> Not to mention that every single deep upgrade takes significantly
>> longer to calculate because of the more complex dependency tree.
>
> This is kind of marginal difference, you already have so much junk
> installed that you hardly can blame KDE-meta for this, just take a
> look at the bloated Gnome2 that so many Gentoo users has installed.

I've never used Gnome, but I can tell you that KDE-meta literally
doubled the number of installed packages on one of my machines, and
added 40% to another. That's something you can feel when waiting for
portage to churn through them. It's not a long wait, no, but it's
annoying because it's short enough that you can't really go do something
else, yet long enough to frustrate you in the end.

>> You just have to sit there and wait for portage to churn through it
>> all, every time. For a slow machine I would actually much prefer the
>> old monolithic ebuilds.
>
> There are many things that could make things a lot better for a slow
> machine, a well working portage instead of the python engined file
> collection.

I fail to see why people keep naming python as the reason why portage is
slow. If that was the case, then why is esearch so fast? No, it's a
deeper problem with the design of portage, but at this time there isn't
really a good alternative. Work is being done, however.

--
PeKaJe

Yeah, but they are good at making toys. I mean look at Windows...
-- From a Slashdot.org post about Microsoft's X-Box console