Gentoo Forums

Posted: **Sat Apr 07, 2007 3:57 am**

When I had a slower, full hard disk, when a compile failed I'd have to correct it/patch it manually then run the "ebuild" subcommands to avoid having wasted the compile time. This is much nicer

Agreed.

Posted: **Sun Apr 08, 2007 1:19 am**

Paapaa wrote:What does command line switches got to do with being interactive?

Well the classic UNIX method is to have switches to turn features on and off. So instead of having to "modify the bashrc to skip testing packages that fail the test phase," it could be the default with a switch to turn it off for non-interactive use, if that is indeed stopped by such a feature. It could of course be the other way round, although i personally think commands should default to working for a user at the shell, since scriptwriters should read the man page.

Posted: **Sun Apr 08, 2007 2:09 am**

steveL wrote:
Paapaa wrote:What does command line switches got to do with being interactive?
Well the classic UNIX method is to have switches to turn features on and off. So instead of having to "modify the bashrc to skip testing packages that fail the test phase," it could be the default with a switch to turn it off for non-interactive use, if that is indeed stopped by such a feature. It could of course be the other way round, although i personally think commands should default to working for a user at the shell, since scriptwriters should read the man page.

Do you ever think before you post?

Posted: **Sun Apr 08, 2007 6:27 pm**

Conan wrote:Do you ever think before you post?

I could ask you the same. Please read the forum guidelines again. Your reaction above is both rather unprofessional and unnecessary. It reflects a kind of attitude we don't exactly encourage here.

Posted: **Tue Apr 10, 2007 4:24 am**

steveL wrote: So instead of having to "modify the bashrc to skip testing packages that fail the test phase," it could be the default with a switch to turn it off for non-interactive use

I think the entire point of "failing install if test fails" is deliberate, to bring to the attention both to package maintainers as well as users that the tests fails and this is serious enough that it should be fixed.

To be honest I actually think its a good idea to do this. It's not really surprising that many upstream developers think of gentoo users as a bunch of ricers when they put a lot of effort into providing a test suite for their software and then even gentoo devs has the POV that "oh, this is not important, i wont bother make sure it even works because the package works fine on my computer".

Posted: **Tue Apr 10, 2007 4:28 am**

STEDevil wrote:
steveL wrote: So instead of having to "modify the bashrc to skip testing packages that fail the test phase," it could be the default with a switch to turn it off for non-interactive use
I think the entire point of "failing install if test fails" is deliberate, to bring to the attention both to package maintainers as well as users that the tests fails and this is serious enough that it should be fixed.

To be honest I actually think its a good idea to do this. It's not really surprising that many upstream developers think of gentoo users as a bunch of ricers when they put a lot of effort into providing a test suite for their software and then even gentoo devs has the POV that "oh, this is not important, i wont bother make sure it even works because the package works fine on my computer".

... except thats not at all what happens.

The test suites are run before stabilizing packages, by the maintainers and testers. It just adds more time for users to run the tests (some take a really long time and a whole bunch of extra dependancies) when the package is expected to be stable. In addition some test suites simply do not work, glibc's for example, even though the package works fine.

Posted: **Tue Apr 10, 2007 11:34 am**

Conan wrote:The test suites are run before stabilizing packages, by the maintainers and testers.

Your reasoning fails the logic test... Either the test suit works or it doesnt. There is no middle ground here.
So if you are correct and test suits works fine before packages are added then how come I have spent the last few days with continuous interruptions from failing tests installing ARCH?

Going from a 2006.1 Live CD to a world upgrade I had so far the following packages fail their test
python|ruby|gnome-vfs|libbonoboui|gnome-doc-utils|nautilus|sound-juicer|eog|gnome-python-desktop|poppler-bindings \
|gnome-session|IO-Socket-INET6

If it is only down to missing deps, exactly what unneeded packages that take oh so long time to install do I need to make these tests be unbroken?

Remember, updating world in this case takes several days on most machines, so is that extra time really an issue compared to all the problems & time a possibly broken package could give you? And if compile time is such a huge issue, then why on earth would one even use a source based distro? Wouldnt eg Ubuntu be the perfect dist instead then?

In any case, if you think Im wrong in my reasoning please explain why, because right now your POV to me feels very much like the argument "I wont bother with coding web pages to W3C standards because it takes longer time for me and they work perfectly fine for me in IE as it is".

edit by nixnut: inserted a break to prevent layout breakage

Posted: **Tue Apr 10, 2007 1:52 pm**

Did you read the part of my post where I said "In addition some test suites are just plain broken"?

Posted: **Tue Apr 10, 2007 4:20 pm**

Conan wrote:Did you read the part of my post where I said "In addition some test suites are just plain broken"?

Yes.

Posted: **Sun Apr 15, 2007 7:23 am**

Remember, updating world in this case takes several days on most machines, so is that extra time really an issue compared to all the problems & time a possibly broken package could give you? And if compile time is such a huge issue, then why on earth would one even use a source based distro? Wouldn't eg Ubuntu be the perfect dist instead then?

Ubuntu is not Gentoo-bin. It is not all about compile times.

But breakage are an argument. I don't care if I do 10 min test or 50 min as long as the install runs through nicely. But it does not and the usefulness of the additional test seem to be strongly limited. I mean they do not help me keeping my system up to date, and in the shape they are they seem not to help anyone to use them. It looks like it is all rubbish to me.
But as always I do have the user choice to switch the test off in using export SKIP_FUNCTIONS="test".

My 2 cents

[edit]I stay with paludis for the vote.
I like the featurelist. I dont care if portage is still around.
[/edit]

Posted: **Sun Apr 15, 2007 3:32 pm**

legine wrote:Ubuntu is not Gentoo-bin. It is not all about compile times.

So? Replace Ubunto with eg Sabayon if you want. The point was that compile times was a non issue.

But breakage are an argument. I don't care if I do 10 min test or 50 min as long as the install runs through nicely. But it does not and the usefulness of the additional test seem to be strongly limited. I mean they do not help me keeping my system up to date, and in the shape they are they seem not to help anyone to use them. It looks like it is all rubbish to me.

Agreed, the issue however really is if the tests could give a benefit if they where all made to work properly (not counting upstream breakage, only Gentoo breakage). To me it feels apparent that at least the people making Paludis are confident it would be beneficial, thus the error presented.

Also, fixing up the ebuilds to work properly even with the tests probably means the useflag test would be used a lot more and if +test the ebuild should pull in the test deps and if -test not pull them in (and Paludis NOT stopping for failed tests). We will see what happens in the future.

Posted: **Thu Apr 19, 2007 9:07 pm**

About tests

I like running tests, because I usualy use a combination of packages that includes some masked ones, too. Currently binutils and glibc. This two packages influence every other package, so the test would show potential problems if it was functional.

But packages fail tests even without using masked/patched binutils or glibc (or any other package). That is not good. Devs can't test all possible combinations of packages installed on one's system, so that's why tests are there.
And in my opinion the tests should be functional (not broken) so users can check their choice/combination of packages.

It's much better for a package to fail a test than to bork a system, resulting in possibly huge problems and time loss.

Ok,
thats my 2 (euro) cents

--- edit ---

Perhaps a new option on bugzilla for failing tests wouldn't be such a bad idea.

Posted: **Thu Apr 19, 2007 9:13 pm**

What's this Plaudis thing I keep hearing about? I know it's a package manager and that the lead dev keeps getting into scraps with other Gentoo devs, but, being the lazy person I am, is there any compelling reason for me to switch to it? I used portage to set up my entire system and it's pretty much the way I want it, so is there any point in using Plaudis now?

Posted: **Thu Apr 19, 2007 9:18 pm**

sonicbhoc
http://paludis.pioto.org/portagedifferences.html shoul tell you more, but you can check the whole site for more info.

Copying everything here wouldn't really make sence.

--- edit ---

maybe this article would help you, too: The Paludis 'Killer Feature'?
It's a few months old, so some things were already changed/added to Paludis.

--- edit 2 ---

sanse --> sence (bad keyboard, bad keyboard)

Posted: **Thu Apr 19, 2007 9:41 pm**

uh... you spelled "sense" wrong.

Doesn't sound too hard to migrate, so I'll try it on my dummy box later. But on my brand-new computer I'm kinda skeptical...
Rather, afraid and lazy.

Posted: **Thu Apr 19, 2007 11:09 pm**

i didn't try, but you can now use

Code: Select all

paludis -E portage ....

to use portage's environment, afaik. To try it easier maybe ....

But do read FAQ first!!!

Posted: **Tue Apr 24, 2007 11:38 am**

Well, I tried out paludis, but didn't stick with it. Not that I don't like the idea. But it wasn't as friendly with slow internet connections(read, resuming downloads don't work correctly, no getdelta). Also, the package manager isn't as easy to read from a usability standpoint(maybe it is just I am used to portage). I do look forward to it getting better and putting pressure on portage.

I like how you can make hooks(should probably make one for getdelta) and how it is so customizable.

Cheers.

Posted: **Wed May 09, 2007 6:29 pm**

Portage is more easy and has some cool additional stuff (emerge-delta-webrsync, eix etc, dispatch-conf), but paludis is more powerful, some of these utilities support paludis but most of all is buggy. Portage have a lot of good documentation, FAQs, articles, while paludis have worse support.

But I use paludis about month and going to stay with paludis.

Posted: **Fri May 11, 2007 12:01 am**

serzh-z wrote:Portage is more easy and has some cool additional stuff (emerge-delta-webrsync, eix etc, dispatch-conf), but paludis is more powerful, some of these utilities support paludis but most of all is buggy. Portage have a lot of good documentation, FAQs, articles, while paludis have worse support.

But I use paludis about month and going to stay with paludis.

Sorry, but i have to correct your statement. Portage doesn't have eix, eix is a standalone app, besides eix works with paludis (using update-eix hook). Author of cfg-update added paludis suport. There is also etc-update patched for use with paludis, too....

P.S.: Writing with a left hand, when learned to write with the right one, seems hard, too. (about which manager is easiesr...)

Posted: **Fri May 11, 2007 2:34 pm**

Well, after seeing .24.2 come out I decided to take the plunge(again!). What I really like is how easy it is to switch back and forth(Not too many people emphasize this).

It is working great(Reduced my installed packages by 100 because of unnecessary deps). My one thing I am missing(other than not being used to it) is getdelta. But that is another issue that I'll be posting about later.

Posted: **Fri May 11, 2007 6:36 pm**

Providing a generic INSTALL doc, and worthless README doesn't really help this much. I did a make uninstall, as it was bitching about a paludisbuild user and group that I didn't know needed creation. I followed the basic instructions of portage migration and make. Short fix was a make uninstall until it is ready for installation. I'm sure I'll get called a moron for posting this, but whatever. This isn't even an answerable question until paludis has an actually INSTALL doc that isn't cut and paste. I'd love to use it, but would like to at least know what I need to do to make it actually function on a working Gentoo box.

Posted: **Fri May 11, 2007 8:11 pm**

wendall911 wrote:Providing a generic INSTALL doc, and worthless README doesn't really help this much. I did a make uninstall, as it was bitching about a paludisbuild user and group that I didn't know needed creation. I followed the basic instructions of portage migration and make. Short fix was a make uninstall until it is ready for installation. I'm sure I'll get called a moron for posting this, but whatever. This isn't even an answerable question until paludis has an actually INSTALL doc that isn't cut and paste. I'd love to use it, but would like to at least know what I need to do to make it actually function on a working Gentoo box.

Code: Select all

emerge paludis

of course first apply the portage2paludis bash-scripts

Code: Select all

mkdir -p /var/cache/paludis/metadata
chown -R root:paludisbuild /var/cache/paludis

chown -R root:paludisbuild /usr/portage
chown -R root:paludisbuild /usr/local/portage
chown -R root:paludisbuild /etc/paludis

Code: Select all

mkdir -p /usr/local/portage/.cache/names

for each additional repository (only needs to be done once)

name the profiles in ./profiles/repo_name

Posted: **Fri May 11, 2007 8:12 pm**

Paludis is installable by Portage, supports all the standard "make" targets (described in the INSTALL file), and there are fine configuration and migration guides on the website and in the "doc" dir (built by make).

If Paludis had a Paludis-specific, complete INSTALL file, that would be an exception in the Linux world.

Posted: **Fri May 11, 2007 8:31 pm**

Thanks guys for the feedback. I didn't even think to try portage for installing paludis. I do agree having a complete INSTALL file is a lot to ask for.

But hey, I can always ask. Will install and give it a shot. Looking forward to binary support.

Posted: **Sat May 12, 2007 12:16 am**

Ok, I have managed to get getdelta working(partially). I do have one question.

If I set

Code: Select all

export SANDBOX_WRITE="/"

in /etc/paludis/bashrc, it fixes a problem with getdelta trying to access a million and one files and causing sandbox violations. Is there, however, a way to set sandbox violations OK as long as it is fetching the sources and not doing something else(i.e. installing)?

Gentoo Forums

Are you satisfied with Paludis

Install

Re: Install