Are you satisfied with Paludis

[tanderson]

Simple: I unmerged paludis very fast again.
But: (This applies to 0.36.0, which I downloaded to read some of the sources.)

• 2103 files in 81 folders. This much for a package manager?
• The .cc files contain a total of 7102 include statements instead of their headers. <- Smells like circular dependencies, even if that impression is wrong.
• It is mixed up of C, C++, ObjC, ruby, python and shell scripts. That neither creates any trust in reliability nor speed.

What's wrong with a large codebase? It has quite a few more features than any other ebuild-capable package manager as well as the ability handle a good deal more than ebuilds.

If you don't know the codebase(and that doesn't include doing a grep for include statements), then you can't possibly know if there is something wrong with the number of include statement in .cc files instead of header files.

I'm pretty sure there are no ObjC files. Even so, the number of C files is extremely low(for a few utilities I think). Ruby and Python are bindings, is there something wrong with bindings? The bulk of the code is C++, and you do of course need shell scripts since ebuilds are written in bash. Did you think about the reasons for these before posting? To further push this, portage itself is a mix of C, python, and shell scripts. oh noes, does that make it a bad package manager.

EDIT: Paludis has no C files, my memory fails me. That pushes it down to C++ and bash for the core code. The bindings of course require their own languages.

I think you're grasping for straws to misrepresent paludis here.

[Paapaa]

"You want make the header file as minimal as possible (for speed/memory usage, for example)"
No. The final compiled and linked product won't gain anything out of "minimal header files" unless there is something seriously wrong with the unrderlying base design of the program. It just might compile a bit faster, but that's an illusion, too. No matter where you pull them in, they are pulled in.
But again, that's more philisophical than anything else.

That is incorrect if you think a situation where you already have compiled foo.cc. Let's say you have 1000 other source files which include foo.h. It is better to have foo.h as simple as possible and have as much included in foo.cc as possible. (Include guards help, of course, but the point remaisn valid) It also helps to keep the interface clean and hide all the details in implementation. IMO it would be stupid to put everything possible in .h. I also think nobody does it. That is NOT an ideal case...

And the circular dependency thing is just ridiculous. I'd think that circular dependencies are catched by compiling the program, not by counting include statements in .cc files...And trust me, Paludis compiles just fine

Well, I don't know a reason WHY Paludis needs more than one language, because I didn't write it. So it's quite impossible for me right now to understand the reasons and it would be a waste of time to dive deep enough into the code to do so.

Yes, and that is the exact reason why you should not be questioning things you can't understand - and even shouldn't.

[ArneBab]

And trust me, Paludis compiles just fine

Did you manage to reduce the compile times?

Last time I compiled it, Paludis took hours to finish (more than a few months ago).

Yes, and that is the exact reason why you should not be questioning things you can't understand - and even shouldn't.

You should question everything which has an impact on you.

In my experience, looking at the ebuild is a good starting point for that, though:

Code: Select all

COMMON_DEPEND="
	>=app-admin/eselect-1.0.2
	>=app-admin/eselect-news-20071201
	>=app-shells/bash-3
	inquisitio? ( dev-libs/pcre++ )
	python-bindings? ( >=dev-lang/python-2.4 >=dev-libs/boost-1.33.1-r1 )
	qa? ( dev-libs/pcre++ >=dev-libs/libxml2-2.6 app-crypt/gnupg )
	ruby-bindings? ( >=dev-lang/ruby-1.8 )
	xml? ( >=dev-libs/libxml2-2.6 )"

DEPEND="${COMMON_DEPEND}
	doc? (
		|| ( >=app-doc/doxygen-1.5.3 <=app-doc/doxygen-1.5.1 )
		media-gfx/imagemagick
		python-bindings? ( dev-python/epydoc dev-python/pygments )
		ruby-bindings? ( dev-ruby/syntax dev-ruby/allison )
	)
	dev-util/pkgconfig"

RDEPEND="${COMMON_DEPEND}
	sys-apps/sandbox"

# Keep this as a PDEPEND. It avoids issues when Paludis is used as the
# default virtual/portage provider.
PDEPEND="
	vim-syntax? ( >=app-editors/vim-core-7 )"

Seems like it needs Python and Ruby only if the respective bindings are activated.

[Paapaa]

Did you manage to reduce the compile times?
Last time I compiled it, Paludis took hours to finish (more than a few months ago).

I guess that depends on your hardware. I have an "old" Core2Duo and the compile time is about 8 minutes (Paludis 0.36.0) - and I browsed the web at the same time. So on a remotely modern hardware it is a non-issue.

Yes, and that is the exact reason why you should not be questioning things you can't understand - and even shouldn't.

You should question everything which has an impact on you.

Why should the OP care at all the number of source files? Why should he care about the number of include directives? Those are nothing any user should care about as those don't impact anything.

I agree that he _might_ care about the programming language dependencies but that was covered already. As has been said: Ruby and Python are optional. And bash is needed because ebuilds need it. So basically Paludis is just C++.

[ArneBab]

Did you manage to reduce the compile times?
Last time I compiled it, Paludis took hours to finish (more than a few months ago).

I guess that depends on your hardware. I have an "old" Core2Duo and the compile time is about 8 minutes (Paludis 0.36.0) - and I browsed the web at the same time. So on a remotely modern hardware it is a non-issue.

Then I hope it's improved.

This won't get me to use Paludis, though, because its interface simply isn't usable to me (and I don't like the way it splits the ebuilds between general ebuilds and paludis only ebuilds).

Besides: A dependency on Python isn't that evil. Last time I compiled it, Python took under 6 minutes - under considerable load (my Computer's almost always under load). In exchange, all Python programs install far faster than C++ Programs (no full compile needed).

[Paapaa]

This won't get me to use Paludis, though, because its interface simply isn't usable to me

What do you mean by "usable"? But it is true that it is different than Portage UI. So if you just want identical UI, switching to Paludis is hard, I guess. I don't find anything unusable in Paludis UI and it has worked just fine for over one year.

(and I don't like the way it splits the ebuilds between general ebuilds and paludis only ebuilds).

Never noticed this. What are "Paludis only ebuilds"? Any example?

[justinkb]

i guess he refers to exheres-0 ebuilds... why i don't think you can use under gentoo anyway?

[ArneBab]

What do you mean by "usable"? But it is true that it is different than Portage UI. So if you just want identical UI, switching to Paludis is hard, I guess. I don't find anything unusable in Paludis UI and it has worked just fine for over one year.

It's already been said a few times, but so be it:

Code: Select all

paludis --some-damn-long-option --another-damn-long-option --a-third-damn-long-option --pretend little_package

paludis --some-damn-long-option --another-damn-long-option --a-third-damn-long-option little_package

That's unusable.

Reasons:

* I have to type damn much
* I make too many typos and have to repeat the command
* No "fire and checkback" - I always have to remember and edit the last command instead of saying "--ask"/"-a" and then just hitting enter if I'm satisfied.

If I'd always need all the options, that would be not that much of a problem (alias "paludis=paludis --many-damn-long-options"), but that's simply not the case.

Never noticed this. What are "Paludis only ebuilds"? Any example?

Do you remember the old KDE 4 overlay (for kde-4.0)?

It was paludis only, so most people couldn't use it, except by switching to paludis.

I decided back then that the live ebuilds weren't worth haggling anymore with paludis and waited (and asked) for a portage compatible overlay. When that came by, I tested every new version of KDE 4.

[Paapaa]

* I have to type damn much
* I make too many typos and have to repeat the command
* No "fire and checkback" - I always have to remember and edit the last command instead of saying "--ask"/"-a" and then just hitting enter if I'm satisfied.

If I'd always need all the options, that would be not that much of a problem (alias "paludis=paludis --many-damn-long-options"), but that's simply not the case.

Ok, you don't like the long options. But what would be best the solution? The only long option I use more often than very rarely is "--uninstall-unused" but other than that I need them so rarely it is not a problem in normal usage. This is what I need mostly:

1. paludis -s
2. paludis -pi world
3. paludis -pi package
4. paludis -pu package

That's it. It's hard to satisfy everyone since there are only a limited number of single letter options.

Do you remember the old KDE 4 overlay (for kde-4.0)?

It was paludis only, so most people couldn't use it, except by switching to paludis.

Actually I'm not familiar with that case. I guess that is a rare case since this is the first time I hear about Paludis only ebuilds.

[ArneBab]

1. paludis -s
2. paludis -pi world
3. paludis -pi package
4. paludis -pu package

That looks like paludis now does have short options. When I last tried it, paludis had only the long options, leading to me having to say

Code: Select all

paludis --pretend --update world

And that is what I find unusable. If you changed it (and now have an --ask/-a option) the UI should be improved now.

Actually I'm not familiar with that case. I guess that is a rare case since this is the first time I hear about Paludis only ebuilds.

They used Paludis only options which made their overlay incompatible with portage, stating "just switch to paludis when you want to use our overlay. (Yes, that means you won't be able to switch back before the package made it into the main tree, and you'll have to work to migrate your install then - or just stick with paludis)". You can imagine that this didn't really make me want to use paludis...

Don't get people to use stuff which isn't and likely won't be supported by portage. It splits the community. (it's something else if you do stuff which portage will support - and make sure that it's compatible)

For me, the only real value in paludis is that it helped speed up portage development (sorry if that sounds offensive. It's simply how it is - paludis didn't give me anythign else). If I need an alternate package manager, I can use pkgcore whose development often helps portage directly (including code-sharing).

[Paapaa]

That looks like paludis now does have short options. When I last tried it, paludis had only the long options, leading to me having to say

I don't know. Paludis has had short options for basic tasks at least since year 2006. So it must've been a long time you tried Paludis? Actually I believe Plaudis had short options always. I suggest reading the manual to see all the possibilities.

They used Paludis only options which made their overlay incompatible with portage, stating "just switch to paludis when you want to use our overlay. (Yes, that means you won't be able to switch back before the package made it into the main tree, and you'll have to work to migrate your install then - or just stick with paludis)". You can imagine that this didn't really make me want to use paludis...

Sounds very odd, I agree. But you blame Paludis for this. Shouldn't you balme the overlay maintainers, instead? (Don't know if they were the same people, but anyway...)

For me, the only real value in paludis is that it helped speed up portage development (sorry if that sounds offensive. It's simply how it is - paludis didn't give me anythign else). If I need an alternate package manager, I can use pkgcore whose development often helps portage directly (including code-sharing).

That is an important thing and I agree that Paludis has greatly sped up Portage development and Paludis devs have done great things stabilizing and standardizing package management (PMS).

BTW, I'm not a Paludis dev/tester/anything. You wrote "you" in that way

[Ormaaj]

I switched back to portage. I didn't understand paludis. I really gave it a good try. I used it for several months, but I just couldn't understand the documentation well enough to use it as well as portage. It seemed 99% of the documentation had to do with the api and not general use. If I had a problem, there was no way to find an answer.

There were many things I liked better than portage, such as its proper reverse dependency resolution, configuration file layout, and how it handled overlays.

Portage has --jobs which makes it faster (maybe they've developed parallel building since then). Now that portage supports sets, that removes yet another need for paludis. I really don't have any problems with portage other than its reverse deps, and the fact that it can't handle building to a chroot very well as prefix portage and paludis.

Paludis' developers seemed quite hostile towards just about everyone. Everything was "the wrong way", and their development model is very stubborn. I can't see a future for them that way.

Maybe i'll give it another try if it becomes more understandable and supported.

[ArneBab]

I don't know. Paludis has had short options for basic tasks at least since year 2006. So it must've been a long time you tried Paludis? Actually I believe Plaudis had short options always. I suggest reading the manual to see all the possibilities.

I did read parts of the manual, but I didn't find the part about short options.

I didn't read the whole manual, though. If the programmers expect me to read the whole manual just for basic usage, I am not their target group.

(sorry if the you sounded wrong - I tried to avoid it here ).

[justinkb]

what's stopping you from creating a wrapper around paludis to make short options, if that is the only reason for you not to use it?

[ArneBab]

what's stopping you from creating a wrapper around paludis to make short options, if that is the only reason for you not to use it?

Wasted time - Portage already has all that usability, and for Paludis I'd have to maintain that wrapper, if they decide to change something.

(think the tries at easier git frontends which stopped working when git changed the command syntax)

[Paapaa]

I didn't read the whole manual, though. If the programmers expect me to read the whole manual just for basic usage, I am not their target group. .

Just type:

paludis --help

The short commands are shown in the beginning. No need to read the whole thing. Takes only about 2 seconds. Learning portage took the same time. There should be no difference here.

With CLI programs you just HAVE TO read the manual. Otherwise you simply won't be able to use them at all.

[Paapaa]

I switched back to portage. I didn't understand paludis. I really gave it a good try. I used it for several months, but I just couldn't understand the documentation well enough to use it as well as portage. It seemed 99% of the documentation had to do with the api and not general use. If I had a problem, there was no way to find an answer.

Did you post here to get support? Of course the docs/FAQ could always be better. But all my problems have been solved either here or in IRC.

Paludis' developers seemed quite hostile towards just about everyone. Everything was "the wrong way", and their development model is very stubborn. I can't see a future for them that way.

Don't know about that. All my (often very stupid) questions have been politely answered in #paludis. But YMMV.

[Bill Cosby]

I switched back to portage. I didn't understand paludis.

What did you want to do,but couldn't?

I am wondering, it is certainly clear that people don't like change if they got used to something, but I fell in love with paludis being consequential, and I value that very much. Not to mention the mere dependency handling that took portage quite some time to follow (and still didn't really catch up IMO), and which drove me nuts on Gentoo with portage, and those lame excuses why it wasn't implemented .

[gringo]

i switched back to portage just before contrarius was dropped IIRC, crosscompiling is sth. i really need. And btw, contrarius never really worked quite well, for me at least.
This was a long time ago and i have no idea if there is an alternative now, i haven´t checked, i´m quite ok with portage right now.

I am wondering, it is certainly clear that people don't like change if they got used to something, but I fell in love with paludis being consequential, and I value that very much

i agree, almost the same happened to me.

Don't know about that. All my (often very stupid) questions have been politely answered in #paludis. But YMMV.

haven´t ever asked on #paludis ( i don´t like irc that much) but mailed Ciaran directly a few times long time ago and got a polite and insightfull answer, that´s all i can say.


And i also have to agree about the long command options paludis has ( or had), i remember having a few aliases to make it more nice for me.

But other than that, there isn´t really much to bitch about, maybe some of my points aren´t valid anymore, it´s been a long time since i last played with paludis.

cheers

[Lepaca Kliffoth]

I use paludis because there is no rational argument against it and Portage is both slower an behind the curve. I get huge kicks out of threads like this one, though; seeing people grasp at anything they can find to try to explain why paludis is bad is just priceless. Threads like this one are also the only ones where you can see Gentooers complain about compile times (because that's about the only one thing one can say that is both against paludis and in favor of portage without sounding completely retarded), that one is always good for a laugh.

I plan on jumping ship when Exherbo becomes stable. The messages posted by Gentoo devs on the mailing list convinced me long ago that Gentoo has no future, the "I don't like this person so what he says is wrong" issue is that big.

[tanderson]

I use paludis because there is no rational argument against it and Portage is both slower an behind the curve. I get huge kicks out of threads like this one, though; seeing people grasp at anything they can find to try to explain why paludis is bad is just priceless. Threads like this one are also the only ones where you can see Gentooers complain about compile times (because that's about the only one thing one can say that is both against paludis and in favor of portage without sounding completely retarded), that one is always good for a laugh.

QFT

[energyman76b]

so where is portage 'behind it'?

the major argument against paludis:
its devs and fans are very aggressive and like to create an aura of 'we are better than thou' around them.

[Paapaa]

the major argument against paludis:
its devs and fans are very aggressive and like to create an aura of 'we are better than thou' around them.

I don't know... To me it looks like the most aggressive comments come from a few individuals who don't like (for one reason or another) Paludis and its certain devs. But maybe this is a typical POV thing. I don't remember seeing "we are better than you" -kinda comments in a long time. I think most Paludis users just use their computers without creating any kinds of auras...

But I do see comments where the poster doesn't have all the facts. For example: Portage might be behind the curve in some issues but is certainly ahead in some issues. For example: Paludis is not threaded (AFAIK) and Portage can do some things parallel. That is a definite speed advantage in that regard for Portage. I really hope Paludis gets threaded soon - I also have the impression that work is being done to make it happen.

[Naib]

so where is portage 'behind it'?

the major argument against paludis:
its devs and fans are very aggressive and like to create an aura of 'we are better than thou' around them.

its not as far as approved Portage requirements.
The major/valid arguement against paludis is really the options. If you are not use to it typing --I-like-long-options-todo-somthing is well... annoying. Sure there is the usual bash-completion arguement, but you still have to know these options exist (and then the RTFM counter comes).

It will probably be said that long-options and the quantity of options give paludis more power and flexibility todo things (eg I want to upgrade world, but rebuild those that depend on this, but not this...) and yes portage cannot do that on its own (can bash-fu around it with eix and co)

basically both work, both will build what is in the tree, both (should) do what is approved in the PMS so basically it is downto personal preference.
emerge world -uvDNa is just too easy to type... yeryeryer bash-aliases, bash-completion why not do an ebuild in a bash-alias/function then...

as to devs and fans attitude yes it is bad and it doesn't show signs of changing, but if you don't have to interact with them it shouldn't influence your decision to use a piece of software BUT when you do and you get bitten it can put you off. Go check out the BMPx dev's they are bad and 1/2 the reason I stopped using that

[tanderson]

so where is portage 'behind it'?

the major argument against paludis:
its devs and fans are very aggressive and like to create an aura of 'we are better than thou' around them.

its not as far as approved Portage requirements.

That's a useless measurement; portage requirements are approved(at least as far as ebuild specs go) as quickly as portage can deliver them, so it's not possible for a package manager to get ahead here. What you can look at is the number of things paludis has that's getting put in the next EAPIs(a lot, and those that don't go in verbatim are highly influenced by paludis' implementation). Paludis has tons of things hanging around for portage to implement(and subsequently get approved).

Even then, paludis is ahead of portage in things that aren't set as a standard(multi-repository support, searching in repositories not installed on the system, the list goes on)

The major/valid arguement against paludis is really the options. If you are not use to it typing --I-like-long-options-todo-somthing is well... annoying. Sure there is the usual bash-completion arguement, but you still have to know these options exist (and then the RTFM counter comes).

Nope, no RTFM counter from me.
What I will say is that after a bit(took me a few weeks, about the time it took me to understand what all of portage's short options _meant_) you learn them quite well. You can always just type --<tab> and see a full list of commands(and the names are quite intuitive, --dl-upgrade as-needed means exactly what it says it does; --dl-blocks discard too) which makes the long options not that bad(I will admit it is a tradeoff). I would counter that I doubt most gentoo users know exactly what their portage options do, it's just an incantation to them to upgrade.

It will probably be said that long-options and the quantity of options give paludis more power and flexibility todo things (eg I want to upgrade world, but rebuild those that depend on this, but not this...) and yes portage cannot do that on its own (can bash-fu around it with eix and co)

bash-fu and eix existing as a way for portage to do things should tell you something about how portage is limited in that regard.

as to devs and fans attitude yes it is bad and it doesn't show signs of changing, but if you don't have to interact with them it shouldn't influence your decision to use a piece of software BUT when you do and you get bitten it can put you off. Go check out the BMPx dev's they are bad and 1/2 the reason I stopped using that

I've not been put off by their attitude. It's rough to those who don't bother to read the docs, but questions that make some sense are answered readily.

If you don't like using software whose devs are annoying to most people, by all means don't use glibc. Drepper is known to be a jerk a lot, so we should all switch to uclibc. Oh and Linus gets in a lot of flamewars, lets all use FreeBSD. Except that they have their fair share of flamewars and people who are jerks so just all use windows.