Are you satisfied with Paludis

Message

mirekm · Post by **mirekm** » Fri Aug 01, 2008 9:53 am

I don't like to argue with anybody, but it means that right now paludis is useless (at least for me) if it is not able to install binary packages.
From other point of view it is stupid, because even portage and paludis is able to install binary rpm, or deb packages (on based on ebuilds) and it is not able to build/install native gentoo's binary packages.

SnEptUne · Post by **SnEptUne** » Mon Sep 01, 2008 5:55 pm

I am trying paludis on my slow laptop on a fresh installation of Gentoo, hoping it would be faster than portage, but no. It takes even longer, I have waited for like 10 minutes and it is still doing "Creating the CONFIG_PROTECT and CONFIG_PROTECT_MASK lists."

Hypnos · Post by **Hypnos** » Mon Sep 01, 2008 6:37 pm

SnEptUne wrote:I am trying paludis on my slow laptop on a fresh installation of Gentoo, hoping it would be faster than portage, but no. It takes even longer, I have waited for like 10 minutes and it is still doing "Creating the CONFIG_PROTECT and CONFIG_PROTECT_MASK lists."

Just *how* slow is your laptop? Paludis is a C++ application, and potentially can take a lot of RAM (easy enough for you to measure). If you are RAM-limited, Portage could be faster.

SnEptUne · Post by **SnEptUne** » Mon Sep 01, 2008 10:41 pm

Hypnos wrote:
SnEptUne wrote:I am trying paludis on my slow laptop on a fresh installation of Gentoo, hoping it would be faster than portage, but no. It takes even longer, I have waited for like 10 minutes and it is still doing "Creating the CONFIG_PROTECT and CONFIG_PROTECT_MASK lists."
Just *how* slow is your laptop? Paludis is a C++ application, and potentially can take a lot of RAM (easy enough for you to measure). If you are RAM-limited, Portage could be faster.

I have 512MB of RAM on the 1.3Ghz Pentium-M laptop, but it is running firefox and full kde, so around 200-300MB of RAM can be used for compilation. I use distcc anyway, so the actual compilation doesn't take long. It seems like 70% of the installation times for running paludis. -_-

Anyway, I have given up on paludis, it is not ready for intensive use yet. It kept bugging me about mkdir failed; why do I have to create directory for it manually anyway? I also shouldn't need to fix permission problems.

Maybe it is because I am running multiple instances of paludis and playman (sometimes I suspended a process and forgot about it, sometimes I control-break it because I ran out of patience); now my kde respository is broken. From my understanding, it adds "x-" prefix to repositories that hasn't been sync'ed yet, but I have sync'ed it and now it have multiple version of it, both with "x-" prefix and without! I guess the developers need to really test this out. Anyway, this is going out of topic.

I am switching back to portage now.

Hypnos · Post by **Hypnos** » Tue Sep 02, 2008 8:35 pm

There are good reasons for each of these behaviors:

* It's generally bad policy to create directories and reset ownership of files automatically. Imagine that as an administrator you have something set up and some program you just installed comes and alters it without your permission -- annoying, no? And it's a potential security hazard.

* The "x-" prefix is to prevent repo name collisions, in order to be compliant with GLEP 42.

Questions like these are nicely answered at the Paludis website, in the FAQ.

Perhaps if you were more patient you could ponder these things and not run multiple instances when it's not supported ...

thelee · Post by **thelee** » Tue Sep 09, 2008 9:09 am

my $.02

after having no idea what paludis was until about a few weeks ago, i made a tentative trial of it, but haven't looked back since.

i'm in love!

i love the cleaner config files, i love the more robust functionality, the more useful query output, etc. i'm not a package maintainer or anything, so i probably don't know about the improved technical aspects of it, but the end-user side of it is fantastic.

jkoerner · Post by **jkoerner** » Sat Sep 27, 2008 6:21 pm

Shamus397 · Post by **Shamus397** » Tue Sep 30, 2008 2:36 am

Answer: No.

I just went back to portage and unmerged paludis after experimenting with it on my laptop for about four months or so, spurred on by the kde-testing overlay going paludis only.

At first I was fairly impressed with it (it was able to properly merge a package that for some reason had portage baffled) but as time has gone on I just don't have the time or patience to deal with it anymore.

The speed increase was non-existant as someone else above noticed on theirs--sitting on "Creating the CONFIG_PROTECT and CONFIG_PROTECT_MASK lists" and cfg-update. Also, if I simply wanted an update to a single package I had to figure out an incantation that wouldn't pull in deep dependencies which is retarded (I don't need to update gcc for a revbump of stella for cryin' out loud!). Bash completion was no help here either--it never worked even though I had it set up properly with eselect.

The straw that broke the camel's back was the kde-testing overlay and the fact that paludis wouldn't accept the sets (!) in that overlay. Oh, the irony!

I could dick around trying to make it work, or I could just go back to portage which seems to be shaping up quite nicely these days. The choice is a no brainer in my opinion.

So while I applaud paludis for giving portage a much needed kick in the ass, it's au revoir for me. Maybe some day it will replace portage, but that day is not today.

drescherjm · Post by **drescherjm** » Mon Oct 13, 2008 4:30 pm

Answer: Not yet.

I tried paludis over the weekend on the laptop. At first glance it was somewhat faster on somethings and slower on others. I did have one very big problem though. paludis is way too verbose. The problem is after running portage2paludis and then trying to update the system. Every update or build I did failed for package dependency reasons. This was a little expected as I have a lot of keywords and they were not all migrated. The problem is when generating the list of packages to build paludis displays 10 or so lines of output for every single dependency. It is very difficult for me to sift through several thousand lines of output to find what (8 to 15) dependencies failed. Is there a command to either get rid of this crap (less verbose?) or tell me only what packages need fixed?

Hypnos · Post by **Hypnos** » Mon Oct 13, 2008 4:54 pm

drescherjm wrote:[...] Is there a command to either get rid of this crap (less verbose?) or tell me only what packages need fixed?

If you read the man page or the "--help" output, you might find that the "--log-level" and "--show-reasons" switches are of use to you.

Paludis is designed for automated use; the command line tools in the Paludis distribution are thin layers that expose much of the functionality of the core library. These tools favor completeness over simplicity and explicitness over economy.

Since I manage just one machine, I choose to minimize most of these messages and increase verbosity if things don't behave as expected; my PALUDIS_OPTIONS env var:

Code: Select all

--log-level warning --show-reasons none --show-use-descriptions none --show-package-descriptions none --continue-on-failure if-satisfied --with-unused-dependencies --dl-new-slots as-needed --dl-upgrade as-needed

drescherjm · Post by **drescherjm** » Mon Oct 13, 2008 5:59 pm

If you read the man page or the "--help" output, you might find that the "--log-level" and "--show-reasons" switches are of use to you.

I did read the --help (even tried --show-reasons) a few times but there is a very long list of options. Not really complaining about that it's just a little more than I want to sift through on a first usage.

I choose to minimize most of these messages and increase verbosity if things don't behave as expected; my PALUDIS_OPTIONS env var:

Thanks I will try that.

pigeon768 · Post by **pigeon768** » Fri Oct 17, 2008 1:57 pm

Hypnos wrote:* It's generally bad policy to create directories and reset ownership of files automatically. Imagine that as an administrator you have something set up and some program you just installed comes and alters it without your permission -- annoying, no? And it's a potential security hazard.

Changing perms of existing files, I agree. If it's already there, it's there for a reason.

However - files that should exist but don't should be created automatically. Paludis doesn't ask me to create folders or ebuilds for the repositories, doesn't ask me to create folders and files for all the packages it installs.

Hypnos wrote:Perhaps if you were more patient you could ponder these things and not run multiple instances when it's not supported ...

It should be supported. And don't tell me it's a security risk because it allows for DOS conditions - if an untrusted user has write access to /usr/portage/distfiles and /var/tmp/paludis you already allow DOS conditions. Instead of creating a lock file, he could just delete tarfiles or random *.o files in the middle of compilation.

Will I keep paludis? I dunno. I like the config file setup, but I really, really don't like not being able to do parallel installs safely.

edit: added 'safely' at the end there.

Hypnos · Post by **Hypnos** » Fri Oct 17, 2008 3:10 pm

pigeon768 wrote:However - files that should exist but don't should be created automatically. Paludis doesn't ask me to create folders or ebuilds for the repositories, doesn't ask me to create folders and files for all the packages it installs.

It does ask you to create repository directories, and then only fills them when you invoke sync. Most people only notice this when they install an overlay; migrating from Portage this is already done for you.

Paludis' policy is that it will create subdirs only in directories it already owns.

It should be supported. And don't tell me it's a security risk because it allows for DOS conditions - if an untrusted user has write access to /usr/portage/distfiles and /var/tmp/paludis you already allow DOS conditions. Instead of creating a lock file, he could just delete tarfiles or random *.o files in the middle of compilation.

This is precisely why Paludis does not create directories: by creating a directory with some group write permissions pre-specified in the ebuild, it could open a security hole if that group already exists on your system.

So it's up to you, and if you get DOS'd it's your own fault.

As for parallel install invocations, that would be nice, but it seems like it would take an awful lot of work for very little benefit. It's better to use ccache; if you suddenly decide you need to install something more, you can kill the running command, re-invoke the command with the an additional package to install, and hardly lose any work.

pigeon768 · Post by **pigeon768** » Sat Oct 18, 2008 2:46 pm

Do you know how emerge used to manage concurrent emerge processes via lockfiles? I fail to see how such a scheme is difficult to implement, nor do I see how it is a security threat. (as stated on the paludis mailing list)

Hypnos · Post by **Hypnos** » Sun Oct 19, 2008 1:17 am

pigeon768 wrote:Do you know how emerge used to manage concurrent emerge processes via lockfiles?

I vaguely recall something like that, and also that it never worked right, which is why Portage doesn't have it anymore.

I fail to see how such a scheme is difficult to implement, nor do I see how it is a security threat. (as stated on the paludis mailing list)

I don't know off the top of my head what the security threat would be, and don't know the discussion on the Paludis mailing list. But to be of any use you have to lock the cache more intelligently than a global lock; then you may leave yourself open to DOS attacks unless you are very careful ...

ArneBab · Post by **ArneBab** » Fri Oct 31, 2008 10:30 pm

I tried out Paludis and switched back to portage.

My reason was that I got the strong impression (from reading the website and doku to try to figure things out - I no longer know which ones), that the developers of Paludis don't develop a tool which does a job for me, but that they develop a tool which forces me to do my job the way they want me to.

I ran into walls which just seemed unreasonable (I'm sure they make sense, but Portage doesn't have them).

Portage fulfills my needs and it just works.

juantxorena · Post by **juantxorena** » Sun Nov 02, 2008 8:30 pm

Anwer: No

Disclaimer: I uninstalled it some weeks ago, after some months of usage, and I have remembered this thread now, so my opinion is based on older versions of paludis.

I installed paludis because of the promise of higher speed, better overlay handling and various enhacements over portage. There are somethings in portage that I don't like and paludis seems to fix them. Here is a summary about my experience:

- The overlay management is objectively better than in portage. The priority stuff is great. But I found that sometimes I wanted higher priority in some packages in an overlay, but lower in some others, I.E., I wanted some packages from the pro-audio overlay that were also in portage, but I wanted the portage versions of some other packages that were also in pro-audio overlay. The problem is that IMHO the whole overlay thing is a dirty hack over portage, and not a solution. In this case, paludis didn't help me too much, I had to mask and unmask things as usual, although I agree that is easier to do this in paludis.

- Package sets and that kind of things: useful, especially for keywording large list of packages like texlive or octave-forge plugins. Is somewhat exasperating to do this in portage package by package. The compact output of eix helps a lot, but paludis way is better. However, it seems that portage-2.2 supports sets, so this is not an advantage any more.

- Hooks, syncs, etc.: I never really fully understand these things. It seems that they extend the paludis capabilities, like using different RCS, doing stuff in ebuilds, aboid repetitive coding in ebuilds, etc. AFAIK this can be accomplished with eclasses. Maybe the paludis stuff do it better/easier, but is incompatible with portage. Maybe I don't know about this too much, but it doesn't seem to a killer feature. Is definitely not for normal users, and although I haven't done a lot of ebuilds and sometimes I miss some better eclasses for some things, I don't feel the need of something like this.

- Speed: paludis is as slow as portage.

- CLI interface: This is the most critical IMHO. I think that the paludis developers are highly underestimate muscle memory, unconscious typing and usefulness of shortcuts. The lack of an --ask switch surprises me. I have read some reasons, but none of them makes any sense. When I want to install/upgrade something, I use emerge with this option, and if everything looks good, I type "Yes" and I forget about it. With paludis I had to use the command at least two times, one with --pretend and the other one without it. The other thing is the lack of one-letter switches. I never learned the whole update line, which had --dl-reinstall and another long option, or something like that. Nearly everything had a lot of --ultra-long-option stuff. Learning something like "emerge -uDNav world" is quite easy, and I type it in less than a second without watching neither the keyboard nor the screen. I might do the same with paludis if it were something like "paludis -uDNav world", but writing the whole line is time conuming, I can't type it as fast as the portage one, I have to learn the options so well that I can type them unconsciously (much much more difficult to reach that with such long names), and even that the probability of typo is much more higher, since there are more characters.

The last one may seem unimportant and just a cosmetic complain, but not for me. The learning process of "forgetting" the muscle-learned portage commands and re-learning a brand new set of commands is nearly impossible in paludis. As I told before, I never learned even the most used commands. I didn't want to make aliases because I was trying to learn them, but I couldn't do it.

Summarizing, paludis has some nice ideas, but for me it was too much hassle for such a little advantage. One-letters shortcuts and and --ask switch (or better, "-a" switch) would help to its adoption much more than the devs might imagine, but without this and with the new portage-2.2, paludis doesn't seems a much more better package manager that I though it was when I installed it.

justinkb · Post by **justinkb** » Thu Mar 26, 2009 4:40 pm

the dependency resolution alone should have everybody switching from portage to paludis. e.g. when doing a emerge -e world portage actually installs the latest patch for ut2004 before ut2004-data itself, leading to a corrupt installation.

ArneBab · Post by **ArneBab** » Thu Mar 26, 2009 7:42 pm

justinkb wrote:the dependency resolution alone should have everybody switching from portage to paludis. e.g. when doing a emerge -e world portage actually installs the latest patch for ut2004 before ut2004-data itself, leading to a corrupt installation.

Sorry. I tried Paludis myself, and it simply wasn't convenient to use.

Portage might not be perfect, but it works in 99% of the cases, and with Portage I know that I'm on the safer side.

And Portage is written in Python, what's a plus for me, because I can actually read the code

zxy · Post by **zxy** » Fri Mar 27, 2009 9:56 am

ArneBab wrote: Portage might not be perfect, but it works in 99% of the cases, and with Portage I know that I'm on the safer side.

I wouldn't be so sure

ArneBab wrote: And Portage is written in Python, what's a plus for me, because I can actually read the code

And with paludis you can't? IIRC it's still GPL2 so you can read the code, too.

P.S.:
read != understand != be able to patch

Yamakuzure · Post by **Yamakuzure** » Fri Mar 27, 2009 4:32 pm

Simple: I unmerged paludis very fast again.

Note: The version I tried was 0.34.0, so everything stated in this list might be wrong with the current version!

Trying to update world lead to weird text lines without a real message. The only one comprehensible was the last one telling me, that it can't be done. Asking portage I found out that a required package was masked.
If you want to write software that is supposed to replace another software somewhere in the (more or less near) future, you *must not* design an ui that is *completely* different than what the users of the to-be-replaced system are used to.
(On the other hand, if you are working on *commercial* software, and want to make *absolutely* sure that users who switched to your solution will never go back, your ui has to be absolutely different and very hard to learn, of course...)
"--my-freaking-options-are-longer-than-yours-and-have-no-shortcuts"-style command line options are no help either.
When I last looked, paludis was alot slower than portage. I hope that has changed yet.
( deleted )

Paludis seems to be a serious project.

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.

And last but not least

Paludis Homepage wrote:Why not fix Portage?

The Portage codebase is too broken to be fixed.

*should* maybe be edited. It's a) just the authors opinion and should be stated as such, and b) simply wrong.

just my 2 euro-cents

ArneBab · Post by **ArneBab** » Fri Mar 27, 2009 6:53 pm

zxy wrote:read != understand != be able to patch

Seems you understood what I meant

Sure I can read the Paludis code, but I don't really understand it.

With Portage I can understand the code, though I'm not yet at the point where I can write patches (else we'd already have improved binpackage support).

zxy · Post by **zxy** » Fri Mar 27, 2009 7:40 pm

ArneBab wrote:
zxy wrote:read != understand != be able to patch
With Portage I can understand the code, though I'm not yet at the point where I can write patches (else we'd already have improved binpackage support).

Don't worry, there is not many people who understand/can patch that spagetthi.

Paapaa · Post by **Paapaa** » Sat Mar 28, 2009 8:06 am

Yamakuzure wrote:2103 files in 81 folders. This much for a package manager?

So you think it is better to have only one very large main.cc instead of breaking it into smaller entities which are easier to maintain?? I don't understand what is the problem here...

Yamakuzure wrote:The .cc files contain a total of 7102 include statements instead of their headers. <- Smells like circular dependencies, even if that impression is wrong.

Umm, how on earth does the number of include statements in .cc files have anything to do with circular dependencies? If you can put #include is .cc, do it. Why? You want make the header file as minimal as possible (for speed/memory usage, for example). Nothing to do with circular dependencies. Likewise you could prefer forward declarations to include statements.

Yamakuzure wrote:It is mixed up of C, C++, ObjC, ruby, python and shell scripts. That neither creates any trust in reliability nor speed.

If you want to make that conclusion you first need to understand WHY Paludis needs more than one language. Again, I don't see the relation to reliability or speed (in your sense...)

Yamakuzure · Post by **Yamakuzure** » Mon Mar 30, 2009 8:56 am

Don't worry. As long as you devs know what you are doing, everything is fine.

For the includes: Well, a .cc/c/cpp/whatever file consists of the implementation. It's header file consists of the needed definitions. Thus the ideal state would be to have exactly one #include statement in each .cc(/c/cpp/whatever) file, and that is exactly the files own header file. (Pull in dependency declarations is the header files job...)
But then, this is a philosophical thing that has more to do with taste rather than determining whether code is good or not...

But to answer your question: Normally you can find include statments in .c* files when a developer can't get around circular dependencies (like class foo needs class bar to work, but class bar can't be defined without class foo being defined first). That's the reason why I wrote "Smells like circular dependencies, even if that impression is wrong."

"So you think it is better to have only one very large main.cc..."
No. And I didn't say anything like that. It's just odd. But then, Webmin has 14,753 files in 1,084 folders, so never mind.

"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.

"(...)you first need to understand WHY Paludis needs more than one language(...)"
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.

Are you satisfied with Paludis

Would (did) you switch back to portage after installing paludis?