Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

2008/5/31 Duncan <1i5t5.duncan@×××.net>:

> "Hemmann, Volker Armin" <volker.armin.hemmann@××××××××××××.de> posted
> 200805302216.07276.volker.armin.hemmann@××××××××××××.de, excerpted below,
> on  Fri, 30 May 2008 22:16:06 +0200:
>
> > On Freitag, 30. Mai 2008, Duncan wrote:
> >
> >> I've not done paludis due to its lack of binary package support.  Even
> >> tho I'm running only a single computer
> >
> > there is another reason not to use paludis:
> >
> > you can't go back.
> >
> > At least not easily.
>
> Holey moley!  I didn't think I was opening up such a can of worms as the
> subthread indicates! =8^(
>
> FWIW and FWIR (from what I've read) paludis does have a portage
> compatibility mode.  Ciaranm was originally against it (didn't see the
> need), but after it became clear that any ultimate claimant to the status
> off official Gentoo package manager would at least during the transition
> need to maintain compatibility, so people could switch if they needed to,
> compatibility mode was added.
>
> Now, I'm not sure how well it works in practice and I'm really not
> interested at this point because without binary package support, it's
> nothing I'm interested in anyway, but the support is officially there,
> and if it doesn't work, that would be a bug.
>
> Of course, merging out-of-tree packages that portage doesn't support does
> sort of leave you high and dry in terms of switching back, but then, that
> would be part of the deal, rather a feature than a bug.  However, that
> doesn't lessen it as a concern for people who do consider the ability to
> switch back important.
>
> So when I read that the KDE-SVN overlay was going EAPI=kde1, which only
> paludis supported, I thought to myself just as well, then, that I had
> finally found time to test it before that and had made the decision that
> KDE4 trunk simply wasn't going to fit my needs for awhile.


that was some time ago and portage got the EAPI=1 supported in less than a
month of when it got out. but maybe because pkgcore has been already
supporting it, if i'm remembering well. the out-of-tree packages (like the
scm ones) could be removed before switching back. if you have them in world
and run portage on world you'd only get a bunch of warnings of invalid atoms
in world and portage ignoring these atoms. so even with them the
intercompatibility is good. the kde-overlay mantained by bernyh and others
if based on the kdebuild-1 build system which moves everything from the
ebuilds to the eclasses and to the package manager which search the world,
search the package and its linkage and tries to suggest a list of deps as
core and suggested deps. the core deps are the required ones while the non
core could be ignored. for example kdiff would a be suggested dep for the
package krusader. another good thing of paludis is the use of sets that
include a list of packages. i've actually been using them to update live
packages without putting them all hand by hand everytime.

> emerge app a, pmerge app b, emerge app c.
> >
> > The config files are not touched.
>
> > With pkgcore you can switch between pkgcore and portage 'on the fly'.
>
> It's obvious which side of the fence you stand on, but that's not such a
> bad thing. =8^)  As I said, I hadn't intended for this thread to go where
> it went -- I thought I was asking a rather innocent question -- but be
> that as it may, I had been somewhat curious about pkgcore since paludis
> seems to have the more active (combative at times, but ehh) following, so
> there's more info out (some good, some not so good) about paludis than
> about pkgcore.
>
> So seeing someone that's actually using pkgcore is helpful. =8^)
>

does pkgcore has more features than portage?! i seem to remember trying it
about one year ago and it had the same portage features and almost the same
drawbacks, so i've decided to stay with portage that time. (this is just a
question from an ignorant about pkgcore and doesn't want in any way to start
another flame).


> > Paludis on the other hand can only described with 'vendor lock in' and
> > 'gratuitous incompatibilty'. And don't forget that it is slow.
>
> Now this... well, let's just say it's uncalled-for.
>
> As explained above, it does have a compatibility mode.  Further, from all
> the remarks I've seen about paludis, from users, supporters, detractors,
> Gentoo and paludis devs and non-devs alike, this is the first time I've
> seen paludis referred to as "slow".  Rather, everyone (else), including
> detractors who severely criticise it for other reasons, seems to agree
> that speed is not one of its failings -- certainly not as opposed to
> portage.
>
> (I've run into fewer direct comparisons between paludis and pkgcore,
> simply due to the fact that pkgcore devs and users seem to be much more
> inclined to just get on with their business and less apt to be raving
> about how good it is wherever they go.  While the resulting lack of
> widely visible info on pkgcore can be frustrating at times, this less
> combative attitude is certainly appreciated by some.  But then you come
> in with this subthread and change all that...)
>
> > That it also requires a shitload of dependencies and installs more crap
> > than portage and pkgcore combined doesn't make it better.
>
> That'd certainly be in the eye of the beholder.  While I'm a KDE person,
> I can empathize with the GNOME folks who hesitate to install what might
> otherwise be a better KDE app solution (such as k3b), because of all the
> KDE "crap dependencies" it brings with it.  Why?  Because I take the same
> position in regard to GNOME apps.  However, a more mature way to express
> the same dependency issues when discussing an app is to mention that it's
> a KDE (or GNOME) app, with the requisite dependencies (note, nothing
> about shit or crap), so people who use the other desktop may have
> legitimate concerns about dependencies if they don't already use other
> apps requiring this desktop.


the same goes for me, a kde user. i really need some gnome apps like pan or
firefox and just for it i need a big deal of gnome deps. and you should
understand what i'm saying, since you're also an experienced pan users.
about the db issue with klibido, getting back to db-4.5 fixed it. and no,
klibido doesn't support posting. i'll try to look into it after i understand
well the package, and if noone takes it i'll take on to port it to qt4 and
cmake build system. i'm now starting to work on qt4 and this could be an
interesting challenge and could help me improve my skills with it.

Same here.  Doing an emerge --pretend paludis, it doesn't have /that/
> unreasonable a list of new merges, and a good share of the ones it /does/
> have are simply null-package virtuals, already filled by newer gcc
> versions, but with further dependencies if you are still stuck on older
> gcc (3.x, 4.0, even 4.1).  That doesn't make them "crap dependencies", it
> just means the developers are making the most of tools already available
> to them in newer gcc/g++/libstdc++, that users of older gcc versions have
> to merge separately.  This isn't even as bad as the GNOME/KDE thing
> above, because eventually, everyone using gcc/g++ will already have the
> functionality built in, and unlike the GNOME/KDE thing, that's going to
> be pretty much everyone in the open source community.


and that some tools like pcre (always needed by paludis) is now not needed
only by it. as i've said before, mainly xorg has pushed in these deps (of
course the use flags also helped a lot)

> At a last point: don't forget WHO is behind paludis - some of the most
> > abusive persons gentoo has ever seen. The same people responsible for
> > most problems.
> >
> > Abusive, agressive, searching for stuff that is not covered by rules,
> > behave like a rabid ape until everything is covered by rules,
> > suffocating gentoo and then turn into rule nazis and game the system.
> > Yes, this people are behind paludis - and 'exherbo'.
>
>
> Umm... the pot calling the kettle black?  I might agree with some of what
> you say, but this wasn't and isn't the time and the place to debate all
> that or to bring it up.  Doing so simply makes you (and what you are
> attempting to defend by running everything else down, pkgcore in this
> case) look as bad as you say they are.
>
> Until this subthread, I had a bit of respect for pkgcore, because as I
> mentioned above, its developers and users seem to be more concerned with
> just having something that works, rather than being all aggressive about
> it.  I'm glad I finally found someone to talk about it.  I'm rather less
> enthused about the way chosen to do so.  Hopefully, that's an exception
> rather than the rule, as so far it has seemed to be.
>
> So... um... let's try to keep this civil, shall we?  I pointed out a
> possible issue in the form of asking a question, and... it does seem I
> did get one response, from Beso (thanks Beso =8^), directly on point.
>

well, i'm glad that at least it was useful as an answer. also, i'm now
trying to do as you've said with pan and the cached articles, but i find it
somehow long to do. maybe it's because i'm not used to it. so for the moment
being i've gone back with klibido.

-- 
dott. ing. beso