| View previous topic :: View next topic |
| Author |
Message |
nightmorph
Developer
Joined: 23 Jan 2005
Posts: 1200
Location: SoCal
|
 Posted: Thu Feb 17, 2005 11:32 pm Post subject: Gentoo, choice, and ebuilds |
 |
|
Starting this thread as a result of some thoughts in Stage 1 on Stage 3. One of the central tenets of Gentoo is user choice. The distribution gives me the chance to intimately tune my system to what I desire, unlike just about (possibly all) other operating systems out there. I do this by declaring things like CFLAGS, CXXFLAGS, and USEFLAGS so that Portage, the heart of Gentoo, can build software pieces to my specifications. Gentoo Basics 101.
However, ebuild developers are tying my hands behind my back when I am prevented from using certain CFLAGS when I want to compile something. For example, I'm using gcc 3.4.3.20050110 to compile my system, and, eventually my world. Granted, I'm using a package from the unstable branch of x86. However, I should be free to choose the CFLAGS or CXXFLAGS that I desire, because that's my prerogative. Gentoo is supposed to be a powerful tool; dangerous, certainly, if I don't know what I'm doing. But, if I am absolutely certain about the way certain optimization flags work, shouldn't I be allowed to use them in the packages I compile?
But this isn't the case. The compiler I'm using was repeatedly hardmasked out of the Portage directory and then allowed back in, apparently with some revisions. It's not being allowed to compile much of my toolchain or system with a basic CFLAG like -O3. I have a Pentium III processor; I know that something as simple as -O3 is safe. It will increase the code size somewhat, but I have a 30-gig hard drive. Space is not exactly an issue. Furthermore, reading the GCC 3.4 manual gives a pretty clear indication of what flags are might be good ideas for my computer, and what might not. The i368 architecture is clearly documented, so if I pay attention to my compile time choices (there's that word again, choice), I should have a good system.
But the overly protective developers have tied me down apparently "for my own good", preventing me from implementing the very choices that should make Gentoo what it aims to be--stable, powerful, and just about the fastest damn distribution out there, tuned properly.
Please, ebuild/Gentoo/whoever developers, don't prevent us from working with our own systems. Give us some credit for decision-making. If I screw up on a flag setting, then let me learn from my mistake; experimentation and result-reporting leads to an improved OS and computing experience in the future. Certainly there will be some new user who never bothers to read the manual but just ends up burning his hands repeatedly. He might roundly curse the developers for not preventing him from hurting himself. But I don't believe that's the primary concern of the developer. Gentoo is capable of always being on the bleeding edge; in fact, maybe that's where it should be.
At least give the users a chance to find out more about what they and their computers are capable of, and a chance to see where Gentoo can shine. Preventing optimizations like CFLAGS (for example, stripping out a user-specified -O3 and replacing it with -O2 in an ebuild) will, in the long run, only harm the life and reputation of the distribution, as well as increasing user discontent.
To sum up: I already have to fight with Portage, which is none too smart; it can't make a logical guess at the order to emerge packages and dependencies. Often it's completely backwards in this approach. I don't think users need their problems compounded by doing things like stripping out the flags in make.conf (unless they contain spelling errors); make.conf is supposed to be one of the cornerstones of Portage--which is, itself, the heart of Gentoo.
_________________
<UzzaDead> What is CONFIG_USB_MON?
<petteyg> A Jamaican USB configuration?
dirtyepic: "We have more cupholders."
GDP || pkgcore
Last edited by nightmorph on Fri Feb 18, 2005 12:54 am; edited 2 times in total |
|
| Back to top |
|
 |
funduk
n00b
Joined: 17 Jan 2005
Posts: 72
Location: Waterloo, Ontario
|
| Posted: Fri Feb 18, 2005 12:04 am Post subject: |
|
|
I agree. Silly me didn't even know that USE flags and such were being stripped! I usually build stable stuff as I'm relatively new...
How would one know his use flags are being stripped? Would it simply be a matter of watching the compile go by and seeing what is being done?
_________________
Funduk
"Zathras not of this time. You take, Zathras die. You leave, Zathras die. Either way, it is bad for Zathras."
|
|
| Back to top |
|
|
nightmorph
Developer
Joined: 23 Jan 2005
Posts: 1200
Location: SoCal
|
| Posted: Fri Feb 18, 2005 12:16 am Post subject: |
|
|
| funduk wrote: | I agree. Silly me didn't even know that USE flags and such were being stripped! I usually build stable stuff as I'm relatively new...
How would one know his use flags are being stripped? Would it simply be a matter of watching the compile go by and seeing what is being done? |
Indeed, yes. Just watch the output in your xterm and notice that though the basics like -march, -mcpu, and -mtune are kept, the majority of ebuilds strip out some optimization options. The most common culprit is dumbing down an -O flag; especially replacing -O3 with -O2. I've a hard time making sure even things like -fomit-frame-pointer stay in a compile; many times compilations are reduced to "-O2 -march=pentium3 -pipe"; -O3 is removed, even though the worst it could do is increase the file size (on this architecture anyway).
I'm pretty sure that any package can be compiled with any or all optimizations I specify (that is, except for the ones that will break it; in theory I can at least add them in), if only the developers wouldn't strip them out in the ebuilds. Granted, not all optimizations are removed. But the majority are altered in some way if not removed.
That's exactly what I, as an end-user, want to avoid. I practice safe computing habits, and though I'm somewhat on the edge with my CFLAG selection (differing only slightly from the flagset used here), I have a pretty good idea of what will and won't work. It frustrates me that developers are taking things out of my hands because they want to decide what they think is good, and leaving me with few options. If I make a mistake and a package refuses to compile; fine, I've learned a lesson. I change my CFLAGS to more conservative ones, or remove nptl from my USE flags. I should be free to do that--isn't freedom what GNU/Linux is all about, anyway?
_________________
<UzzaDead> What is CONFIG_USB_MON?
<petteyg> A Jamaican USB configuration?
dirtyepic: "We have more cupholders."
GDP || pkgcore |
|
| Back to top |
|
|
ctt
Tux's lil' helper
Joined: 04 Feb 2005
Posts: 136
|
| Posted: Fri Feb 18, 2005 12:24 am Post subject: Re: Gentoo, choice, and ebuilds |
|
|
| nightmorph wrote: | Starting this thread as a result of some thoughts in Stage 1 on Stage 3. One of the central tenets of Gentoo is user choice. The distribution gives me the chance to intimately tune my system to what I desire, unlike just about (possibly all) other operating systems out there. I do this by declaring things like CFLAGS, CXXFLAGS, and USEFLAGS so that Portage, the heart of Gentoo, can build software pieces to my specifications. Gentoo Basics 101.
However, ebuild developers are tying my hands behind my back when I am prevented from using certain CFLAGS when I want to compile something. For example, I'm using gcc 3.4.3.20050110 to compile my system, and, eventually my world. Granted, I'm using a package from the unstable branch of x86. However, I should be free to choose the CFLAGS or CXXFLAGS that I desire, because that's my prerogative. Gentoo is supposed to be a powerful tool; dangerous, certainly, if I don't know what I'm doing. But, if I am absolutely certain about the way certain optimization flags work, shouldn't I be allowed to use them in the packages I compile?
But this isn't the case. The compiler I'm using was repeatedly hardmasked out of the Portage directory and then allowed back in, apparently with some revisions. It's not being allowed to compile much of my toolchain or system with a basic CFLAG like -O3. I have a Pentium III processor; I know that something as simple as -O3 is safe. It will increase the code size somewhat, but I have a 30-gig hard drive. Space is not exactly an issue. Furthermore, reading the GCC 3.4 manual gives a pretty clear indication of what flags are might be good ideas for my computer, and what might not. The i368 architecture is clearly documented, so if I pay attention to my compile time choices (there's that word again, choice), I should have a good system.
But the overly protective developers have tied me down apparently "for my own good", preventing me from implementing the very choices that should make Gentoo what it aims to be--stable, powerful, and just about the fastest damn distribution out there, tuned properly.
Please, ebuild/Gentoo/whoever developers, don't prevent us from working with our own systems. Give us some credit for decision-making. If I screw up on a flag setting, then let me learn from my mistake; experimentation and result-reporting leads to an improved OS and computing experience in the future. Certainly there will be some new user who never bothers to read the manual but just ends up burning his hands repeatedly. He might roundly curse the developers for not preventing him from hurting himself. But I don't believe that's the primary concern of the developer. Gentoo is capable of always being on the bleeding edge; in fact, maybe that's where it should be.
At least give the users a chance to find out more about what they and their computers are capable of, and a chance to see where Gentoo can shine. Preventing optimizations like CFLAGS (for example, stripping out a user-specified -O3 and replacing it with -O2 in an ebuild) will, in the long run, only harm the life and reputation of the distribution, as well as increasing user discontent.
To sum up: I already have to fight with Portage, which is none too smart; it can't make a logical guess at the order to emerge packages and dependencies. Often it's completely backwards in this approach. I don't think users need their problems compounded by doing things like stripping out the flags in make.conf (unless they contain spelling errors); make.conf is supposed to be one of the cornerstones of Portage--which is, itself, the heart of Gentoo. |
One good reason why certain CFLAGS are prohibited is to help control the quality of bug reports to the package maintainer, and upstream developers. If you could just casually have rediculous CFLAGS take effect, and it ends up causing far reaching problems (in the case of GCC, problems could likely spread to other builds) you may not even be aware of why you're having problems. Only when you go ahead and complain to the, say, GCC developers will you notice what the problem really is. Cases like this tend to waste a lot of time, and can't be good for the reputations of Gentoo users.
If, on the other hand, you know exactly what you're doing, you could just rewrite the ebuilds (which, unlike many other distributions, are just plain text scripts) and use whatever options you see fit.
There are probably many more reasons why CFLAGS are rewritten, packages are masked, etc, but this is just one example. In most cases, the solution is similar--at the very worst, rewrite the ebuild so that it works the way you want it to.
_________________
- chris |
|
| Back to top |
|
|
nightmorph
Developer
Joined: 23 Jan 2005
Posts: 1200
Location: SoCal
|
| Posted: Fri Feb 18, 2005 1:13 am Post subject: |
|
|
| ctt wrote: | One good reason why certain CFLAGS are prohibited is to help control the quality of bug reports to the package maintainer, and upstream developers. If you could just casually have rediculous CFLAGS take effect, and it ends up causing far reaching problems (in the case of GCC, problems could likely spread to other builds) you may not even be aware of why you're having problems. Only when you go ahead and complain to the, say, GCC developers will you notice what the problem really is. Cases like this tend to waste a lot of time, and can't be good for the reputations of Gentoo users.
If, on the other hand, you know exactly what you're doing, you could just rewrite the ebuilds (which, unlike many other distributions, are just plain text scripts) and use whatever options you see fit.
There are probably many more reasons why CFLAGS are rewritten, packages are masked, etc, but this is just one example. In most cases, the solution is similar--at the very worst, rewrite the ebuild so that it works the way you want it to. |
CFLAGS exist to be used, not to sit around only as "potentially dangerous options." Yes, inappropriate CFLAG use can make troubleshooting harder if you don't know what you're doing when choosing flags or troubleshooting. Personally, that's the first place I check if a compile can't complete. But many--if not a majority--of CFLAGS are safe provided you know your architecture and any bugs it might contain.
It is not the developer's job to shield me from all the decisions I make as an end-user. I'd like to think that most Gentoo users have some idea of what they're doing; therefore we need to be able to work with our system, instead of fighting the developer. Maybe we'll have to fight with our system through trial and error until we figure out what's wrong. But it's not a developer's place to entirely remove the functions that are built-in to C and C++. In my view what would harm Gentoo more would be word spreading that its alleged customization & optimization abilities are nothing of the sort; users are limited to something less than their hardware & software is capable of.
| Quote: | | at the very worst, rewrite the ebuild so that it works the way you want it to. |
So, your solution for a developer's problem is to become a developer myself? I'm sorry, but I think it's unreasonable to expect all end-users to become experienced programmers. I've delved through the contents of a few ebuilds just to see what they look like, but I've yet to find anything that resembles a "CXXFLAG off switch". The ebuilds themselves generally aren't supposed to be all that customized; it's the user who is supposed to add his input at the user level, by deciding compile options. That is what is needed, not a bunch of hybrid, hacked ebuilds. Gentoo is supposed to be built from the straight source according to my specs; monkeying with ebuilds is not the best way to go about it, nor, I'm sure, in line with the original vision for Portage and gcc.
_________________
<UzzaDead> What is CONFIG_USB_MON?
<petteyg> A Jamaican USB configuration?
dirtyepic: "We have more cupholders."
GDP || pkgcore
Last edited by nightmorph on Fri Feb 18, 2005 1:37 am; edited 1 time in total |
|
| Back to top |
|
|
dirtyepic
Developer
Joined: 22 Oct 2004
Posts: 1525
Location: sk.ca
|
| Posted: Fri Feb 18, 2005 1:15 am Post subject: |
|
|
hmm, i know i left that 10ft pole around here somewhere...
seriously though, could we postpone this for a bit? at least until the last CFLAGS flamefest dies down a little?
just remember, you also have the choice to make your own overlay, the choice to edit the ebuilds to remove the flag stripping, the choice to break your system how you see fit, and the choice to learn from your own mistakes instead of listening to people who have already made them. just because it isn't handed to you in a gift-wrapped package with a ribbon on top and you actually have to _do_ something yourself doesn't equate a limitation of choice or freedom.
if you don't like how they're doing things, then do it yourself. i do, and it's an extremely rewarding experience.
_________________
by design, by neglect
for a fact or just for effect |
|
| Back to top |
|
|
dirtyepic
Developer
Joined: 22 Oct 2004
Posts: 1525
Location: sk.ca
|
| Posted: Fri Feb 18, 2005 1:34 am Post subject: |
|
|
| Quote: | | But many--if not a majority--of CFLAGS are safe provided you know your architecture and any bugs it might contain |
thanks, i needed that laugh.
flags are removed when they are known and proven to break things. just like Firestone tires were recalled when they started exploding in inconvenient places, or how they took Vioxx off the market when they discovered that (ha ha) it actually causes cancer. Sure you have the freedom to get yourself an SUV, put some Firestones on it, swallow a bottle of Vioxx, and cruise the freeway at unsafe speeds. Just don't be expecting anyone to help you do it.
_________________
by design, by neglect
for a fact or just for effect |
|
| Back to top |
|
|
piffle
Tux's lil' helper
Joined: 13 Jun 2004
Posts: 98
|
| Posted: Fri Feb 18, 2005 1:37 am Post subject: |
|
|
| Good grief, is this really all you have to get worked up over in you life? I need that sort of carefree existence. |
|
| Back to top |
|
|
nightmorph
Developer
Joined: 23 Jan 2005
Posts: 1200
Location: SoCal
|
| Posted: Fri Feb 18, 2005 1:51 am Post subject: |
|
|
| dirtyepic wrote: | hmm, i know i left that 10ft pole around here somewhere...
seriously though, could we postpone this for a bit? at least until the last CFLAGS flamefest dies down a little?
just remember, you also have the choice to make your own overlay, the choice to edit the ebuilds to remove the flag stripping, the choice to break your system how you see fit, and the choice to learn from your own mistakes instead of listening to people who have already made them. just because it isn't handed to you in a gift-wrapped package with a ribbon on top and you actually have to _do_ something yourself doesn't equate a limitation of choice or freedom.
if you don't like how they're doing things, then do it yourself. i do, and it's an extremely rewarding experience. |
I suspect that my perspective is colored by the fact that my first Gentoo install (stage 2) went flawlessly. In spite of updating my system almost daily and tinkering here and there with my system, after first having thoroughly read up on the subject at hand, I never once had a break. The only trouble I've had was configuring my xorg.conf to use my USB keyboard and setting the right screen options. In spite of living on the edge the first time around, I never had any of the trouble that I see daily repeated on these forums, so I know there's a better way. Maybe it's just my luck of the draw that I have stable (if dated) hardware.
I'm just seeing so many more possibilities that I could do with my system, so naturally I don't like obstacles, even though the developers may be well-intentioned. And I don't know much about programming for Portage; I haven't found much in the way of specific ebuild editing in the manner you suggest. Overlay HOWTOs are in abundance, though.
And about flag removal--mostly I'm dissatisfied with flags that are removed even though my architecture supports them. Obviously, if I accidentally include an optimization for AMD64, or set one CFLAG without setting a complimentary one, my system will break. I understand that some flags have to be removed if they're problematic on all architectures. But a good reading of the GNU GCC 3.4 manual suggests that all of those flags are possible, if under limited circumstances. But even compilations with gcc 3.3.x--which I would assume to be more stable and documented than 3.4.x--also suffer from flag stripping.
But I don't really see anything "handed" to me at all, in any way; I see it as something more like taking away. Believe me, I love the idea of a safe, stable system. But if it's possible to make one in a more advanced manner (for example, something as ordinary as -O3), I should get the chance to do it. I don't just smash things together left and right, you know. That's probably not the best idea to put it lightly.
_________________
<UzzaDead> What is CONFIG_USB_MON?
<petteyg> A Jamaican USB configuration?
dirtyepic: "We have more cupholders."
GDP || pkgcore |
|
| Back to top |
|
|
Pythonhead
Developer
Joined: 16 Dec 2002
Posts: 1801
Location: Redondo Beach, Republic of Calif.
|
| Posted: Fri Feb 18, 2005 1:51 am Post subject: |
|
|
| I get a kick out of reading http://funroll-loops.org/ so I filter random CFLAGS from random ebuilds to give them fodder like this post. |
|
| Back to top |
|
|
nightmorph
Developer
Joined: 23 Jan 2005
Posts: 1200
Location: SoCal
|
| Posted: Fri Feb 18, 2005 1:54 am Post subject: |
|
|
| Pythonhead wrote: | | I get a kick out of reading http://funroll-loops.org/ so I filter random CFLAGS from random ebuilds to give them fodder like this post. |
Aha! Evil! 
_________________
<UzzaDead> What is CONFIG_USB_MON?
<petteyg> A Jamaican USB configuration?
dirtyepic: "We have more cupholders."
GDP || pkgcore |
|
| Back to top |
|
|
Pythonhead
Developer
Joined: 16 Dec 2002
Posts: 1801
Location: Redondo Beach, Republic of Calif.
|
| Posted: Fri Feb 18, 2005 2:00 am Post subject: |
|
|
Seriously though, what do you propose we do if, for instance, -O3 breaks a package for many people (look in bugzilla, it happens).
Make people edit the ebuild and change it to filter -O3? I think removing a known problem for many people is a better solution than leaving it because some people think it may work for them. |
|
| Back to top |
|
|
nightmorph
Developer
Joined: 23 Jan 2005
Posts: 1200
Location: SoCal
|
| Posted: Fri Feb 18, 2005 2:09 am Post subject: |
|
|
| Pythonhead wrote: | Seriously though, what do you propose we do if, for instance, -O3 breaks a package for many people (look in bugzilla, it happens).
Make people edit the ebuild and change it to -O2? I think removing a known problem for many people is a better solution than leaving it because some people think it may work for them. |
I guess that is a problem--if it does come down to an issue of majority, maybe a percentage of users will have to be made unhappy. It'd be nice to just say that users will keep themselves informed about smart decisions when it comes to setting flags, but that's not a realistic perspective. Hmm, maybe a line in the file's documentation or home page? Something to the effect of "try -O2 with this package" or "this is known to break if -XXXXX is set". Though that might not be feasible, either. I get the impression that most users only set -O2 (for example), choosing something with greater known stability over the chance to further optimize performance.
I don't know, maybe it is better to remove a known problem for most (I'm not sure only "many" qualifies) people than to leave it in an ebuild. Per package CFLAGS and CXXFLAGS would seem to be a solution, but I have yet to find a handy, workable method of doing so. Not that one doesn't exist; I'm still just exploring.
If there is a major/semimajor problem with a package in Portage, such as -O3 breaking it, would the ebuild developers just move it to testing, hardmask it, or just re-write the code and release a new version of it? Or is that sort of thing not really possible when it comes to responding to CFLAG breaks?
_________________
<UzzaDead> What is CONFIG_USB_MON?
<petteyg> A Jamaican USB configuration?
dirtyepic: "We have more cupholders."
GDP || pkgcore |
|
| Back to top |
|
|
Halcy0n
Developer
Joined: 17 Sep 2003
Posts: 1667
Location: Freehold, NJ
|
| Posted: Fri Feb 18, 2005 2:31 am Post subject: |
|
|
| nightmorph wrote: | | I guess that is a problem--if it does come down to an issue of majority, maybe a percentage of users will have to be made unhappy. It'd be nice to just say that users will keep themselves informed about smart decisions when it comes to setting flags, but that's not a realistic perspective. Hmm, maybe a line in the file's documentation or home page? Something to the effect of "try -O2 with this package" or "this is known to break if -XXXXX is set". Though that might not be feasible, either. I get the impression that most users only set -O2 (for example), choosing something with greater known stability over the chance to further optimize performance. |
Or the small percentage of people that think optimizations are magic can alter the ebuilds to produce possibly broken binaries. You can easily copy the ebuild into your overlay and remove the filter flag statements. Just don't file any bugs about it.
| nightmorph wrote: | | If there is a major/semimajor problem with a package in Portage, such as -O3 breaking it, would the ebuild developers just move it to testing, hardmask it, or just re-write the code and release a new version of it? Or is that sort of thing not really possible when it comes to responding to CFLAG breaks? |
I don't think -O3 breaking a program is a major issue, its a very minor issue. If the program works fine with -O2, I don't see the huge problem. Flags are stripped from ebuilds, or filtered down, to make your system usable. I bet if they didn't we'd have loads more people complaining about their systems being broken because of all of the strange flags they use if they weren't stripped where they are known to be bad, but alas, you can't make everyone happy.
_________________
Mark Loeser
http://www.halcy0n.com |
|
| Back to top |
|
|
Bob P
Veteran
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Fri Feb 18, 2005 3:52 am Post subject: |
|
|
i think that nightmorph states his case very honestly, eloquently and clearly. in response, he gets a wise assed response from a developer. i was disappointed to see that.
| Halcy0n wrote: | | I don't think -O3 breaking a program is a major issue, its a very minor issue. If the program works fine with -O2, I don't see the huge problem. Flags are stripped from ebuilds, or filtered down, to make your system usable. I bet if they didn't we'd have loads more people complaining about their systems being broken because of all of the strange flags they use if they weren't stripped where they are known to be bad, but alas, you can't make everyone happy. |
i don't think that -O3 breaking a program is a major issue either. but i do think it is a major issue that some developers are outspoken enough to admit that their primary interest is to filter out the -O3 flag just to make their life easier when it comes time to processing bug reports. when that happens, -O3 really isn't a compilation option in Gentoo. if the Gentoo developers are going to render the distribution incompatible with -O3 just to make the process of wading through the bug reports easier for them, then it is time for Gentoo to be honest with its user base and admit that -O3 isn't actually supported in this distribution.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
ctt
Tux's lil' helper
Joined: 04 Feb 2005
Posts: 136
|
| Posted: Fri Feb 18, 2005 9:09 am Post subject: |
|
|
| Bob P wrote: | | ...if the Gentoo developers are going to render the distribution incompatible with -O3 just to make the process of wading through the bug reports easier for them... |
Although the Gentoo developers have a vested interest in making sure CFLAGS related bugs are not reported to them, another motivation is to sort of shield upstream developers from the same sorts of reports. Nothing will tarnish the reputation of Gentoo users (see http://funroll-loops.org/ -- I tried not to mention it, but oh well) more than a bunch of people complaining to the <insert package name here> developers that the freshly built program simply does not work (build, or, even worse, function properly), and then on later inspection have it pointed out that...
| Code: |
CFLAGS='-march=athlon-xp -m3dnow -msse -mfpmath=sse -mmmx -O3 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args -ffast-math -fprefetch-loop-arrays -fprefetch-loop-arrays -ffast-math -fforce-addr -falign-functions=4 -funroll-loops'
|
...may not be the best choice (with the obligatory, "damned Gentoo users", comment). I think it's great that (in most cases) it becomes increasingly difficult to `cause the system to work strangely', as the resulting strangeness increases. It's a clue that you'll probably know enough about the compiler and your system to set such-and-such option and not complain about the results, iff you're able to figure out how to safely (via the OVERLAY) make yourself a customized ebuild.
_________________
- chris |
|
| Back to top |
|
|
Pythonhead
Developer
Joined: 16 Dec 2002
Posts: 1801
Location: Redondo Beach, Republic of Calif.
|
| Posted: Fri Feb 18, 2005 1:27 pm Post subject: |
|
|
| Bob P wrote: | i think that nightmorph states his case very honestly, eloquently and clearly. in response, he gets a wise assed response from a developer. i was disappointed to see that.
|
I made a joke and then gave a serious reply, give me a break please.
| Bob P wrote: |
i don't think that -O3 breaking a program is a major issue either. but i do think it is a major issue that some developers are outspoken enough to admit that their primary interest is to filter out the -O3 flag just to make their life easier when it comes time to processing bug reports.
|
If you're talking about me, I didn't admit anything like that. My primary interest as a user and developer is to have a working system. I believe I have filtered out exactly one CFLAG (not -O3) which was a known bug upstream and they had no interest in "fixing" either.
| nightmorph wrote: |
If there is a major/semimajor problem with a package in Portage, such as -O3 breaking it, would the ebuild developers just move it to testing, hardmask it, or just re-write the code and release a new version of it? Or is that sort of thing not really possible when it comes to responding to CFLAG breaks?
|
No, I don't think packages known to break should be hardmasked if an offending CFLAG can be filtered. I doubt most upstream authors would spend time trying to track down obscure compile failures or runtime errors because of a CFLAG, so it'd sit masked forever. Would you still be using Gentoo if on your first install you had to keep unmasking packages until it was done? You said it went flawlessly your first time but you might not have had the same opinion if you had to unmask every step of the way.
Personally I hope nobody is spending great amounts of time trying to figure out why a package won't compile with CFLAG x or y. There are plenty of other bugs I'd rather see fixed so more people have flawless installs and working systems. |
|
| Back to top |
|
|
piffle
Tux's lil' helper
Joined: 13 Jun 2004
Posts: 98
|
| Posted: Fri Feb 18, 2005 2:07 pm Post subject: |
|
|
| Quote: | | just to make their life easier when it comes time to processing bug reports. |
You know, if I was donating my time and work freely, for the benefit of others, I'd probably want to make my life easier too. I can't believe all this carping over something so inconsequential. |
|
| Back to top |
|
|
Halcy0n
Developer
Joined: 17 Sep 2003
Posts: 1667
Location: Freehold, NJ
|
| Posted: Fri Feb 18, 2005 2:40 pm Post subject: |
|
|
| piffle wrote: | | You know, if I was donating my time and work freely, for the benefit of others, I'd probably want to make my life easier too. I can't believe all this carping over something so inconsequential. |
You can't make everyone happy, someone will always complain about something. Doesn't matter how much time people dedicate to it, or how small the issue is.
Its very easy to remove the filter-flag statements from ebuilds if you want to. Hell, you could write a sed script in about 10 seconds to remove them all from the tree. Run it after every emerge sync, just don't complain when your packages break.
_________________
Mark Loeser
http://www.halcy0n.com |
|
| Back to top |
|
|
d_m
Guru
Joined: 12 Jun 2003
Posts: 569
Location: Philadelphia, PA, USA
|
| Posted: Fri Feb 18, 2005 4:26 pm Post subject: |
|
|
One suggestion might be to have a flag (not mentioned in install documents) which turns off CFLAG filtering. It would tell people that if the flag is used that bug reports will not be accepted, because flags are usually filtered due to problems and known bugs.
Of course, people might file bug reports anyway. But at least this gives users a choice (while allowing developers to focus on making the software work for the majority of users).
As someone who has always run stable, state3 systems (and appreciates Gentoo because it's easy to set up the way I want) I feel like this would satisfy those who want to run a bleeding edge system, without comprimising the distro for people like me who just want things to work.
_________________
The name that can be named is not the eternal name. |
|
| Back to top |
|
|
Bob P
Veteran
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Fri Feb 18, 2005 4:56 pm Post subject: |
|
|
| Pythonhead wrote: | | Bob P wrote: |
i don't think that -O3 breaking a program is a major issue either. but i do think it is a major issue that some developers are outspoken enough to admit that their primary interest is to filter out the -O3 flag just to make their life easier when it comes time to processing bug reports.
|
If you're talking about me, I didn't admit anything like that. My primary interest as a user and developer is to have a working system. I believe I have filtered out exactly one CFLAG (not -O3) which was a known bug upstream and they had no interest in "fixing" either. |
no, i wasn't talking about you, so i hope you weren't offended. i have seen other devs, though, who very openly stated that all -O3 flags should always be filtered.  if that is going to be the case, it would be more clear if the gentoo docs would openly state that -O3 is not available. imho "clarity" is a desirable trait, and it doesn't do anything for clarity if the idea of quietly stripping -O3 out of all ebuilds while pretending to offer -O3 as an option were to take hold.
i've just read ciarnm's page about guidelines for flag filtering. that sounds like a reasonable approach. granted, some degree of flag filtering in ebuilds is a necessary evil, but i think that a blanket approach of disabling -O3 across the board is unnecessarily evil.
in contrast, it is entirely reasonable to support -O2 in debugging and to assign -O3 submissions a "wontfix" solution. this approach would still provide a wide margin of safety for the majority of users (-O2) while still make -O3 available to people who are willing to try it.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
teknomage1
Veteran
Joined: 05 Aug 2003
Posts: 1239
Location: Los Angeles, CA
|
| Posted: Fri Feb 18, 2005 5:19 pm Post subject: |
|
|
| Isn't this the opposite side of the coin that causes people to complain, "The quality of ebuilds is dropping, I'm going to leave gentoo cause it's too buggy!" ? I mean honestly, those flags are disabled so the package will compile on most machines and work. If you're into the uber-exact options can't you just use chkinstall and compile it yourself? |
|
| Back to top |
|
|
gentoo_lan
l33t
Joined: 07 Sep 2004
Posts: 879
Location: Wright Patterson AFB, OH
|
| Posted: Fri Feb 18, 2005 5:27 pm Post subject: |
|
|
CFLAGS are disabled because they are known to break certain programs. Developers do not have time to waste by working on bugs that can easily be fixed by stripping certain CFLAGS.
| Quote: | | But this isn't the case. The compiler I'm using was repeatedly hardmasked out of the Portage directory and then allowed back in, apparently with some revisions. It's not being allowed to compile much of my toolchain or system with a basic CFLAG like -O3. I have a Pentium III processor; I know that something as simple as -O3 is safe. |
-O3 is not safe in the toolchain. They strip most of the CFLAGS from the toolchain because they cause breakage. If you have a broken toolchain you can kiss your system goodbye.
| Quote: | | But the overly protective developers have tied me down apparently "for my own good", preventing me from implementing the very choices that should make Gentoo what it aims to be--stable, powerful, and just about the fastest damn distribution out there, tuned properly. |
When you waste half of your time telling people to fix CFLAGS because they don't know what they are doing with them in the first place then you probably wouldn't call developers overprotective. You can edit the ebuilds to stop stripping out CFLAGS...that is a choice you could make. Of course you will get zero support from the developers because something breaks. It will be your own fault.
| Quote: | | I already have to fight with Portage, which is none too smart; it can't make a logical guess at the order to emerge packages and dependencies. |
An example of this might be nice. I have never had a problem with portage properly calculating dependencies.
_________________
http://haley.myserver.org - Some ebuilds not in Porgage, Free Linux Games Listings, and more.
Registered Linux user# 375038. |
|
| Back to top |
|
|
Bob P
Veteran
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Fri Feb 18, 2005 5:40 pm Post subject: |
|
|
| gentoo_lan wrote: | | Quote: | | I already have to fight with Portage, which is none too smart; it can't make a logical guess at the order to emerge packages and dependencies. |
An example of this might be nice. I have never had a problem with portage properly calculating dependencies. |
it seems that you misread what he said. he didn't accuse portage of not properly calculating dependencies, which seems to have been your interpretation. he said that it can't make a logical guess at the order (emphasis mine) to emerge packages and dependencies.
indeed, this is a problem with portage and just about every experienced gentoo user has encountered the problem. a search for the string "portage AND stupid" should provide lots of examples that don't need to be itemized here. the problem is so severe that people have actually written complex scripts to prevent portage from borking the toolchain:
http://forums.gentoo.org/viewtopic-t-282474-highlight-emerge+wrapper.html
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
Bob P
Veteran
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Fri Feb 18, 2005 5:47 pm Post subject: |
|
|
| teknomage1 wrote: | | Isn't this the opposite side of the coin that causes people to complain, "The quality of ebuilds is dropping, I'm going to leave gentoo cause it's too buggy!" ? I mean honestly, those flags are disabled so the package will compile on most machines and work. If you're into the uber-exact options can't you just use chkinstall and compile it yourself? |
no, i don't think it is. the gentoo documentation makes it very clear that debugging is supported for the -O2 optimization level, and not for the -O3 optimization level. the recent outcry about the quality of ebuilds dropping has been, afaik, related to ebuilds that break at the -O2 optimization level (where it is a bug if it happens), not at the -O3 optimization level (where it can be expected).
from my seat, it appears that we're actually talking about two distinctly different issues, one being the reliability of ebuilds at the -O2 optimization level, the other being whehter or not the -O3 optimization level is even going to be available in gentoo.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
