Re: [gentoo-dev] rm `which gcc` && emerge -e world
On Friday 21 October 2005 11:12 pm, Tomasz Mloduchowski wrote:
> I got sick of filling 3 almost identical bug reports
please stop doing this
we are already playing with doing this in the wrapper itself so that
compilation is transparent
i'd wager to say the majority of packages in portage run `gcc` and `g++`
rather than ${CTARGET}-gcc
-mike
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] rm `which gcc` && emerge -e world
Now, that I've got your attention. IMHO above should NOT fail - most of
the software in portage is already using ${HOST}-gcc instead and gcc
symlink is just a convenience.
But it does. In packages I will never suspect being nasty (qt, lynx) and
ones I would, but they shouldn't (fuse)
What is so important in that feature? Crosscompilation and distcc.
For example, I have alpha-unknown-linux-gnu running as a distcc server
for x86 box. And, it does not work for those packages.
I got sick of filling 3 almost identical bug reports
110040, 110086 and 110087 and I'm not even at half of emerge -uD world.
So, if you agree that it IS a problem, do the `rm` and run ebuilds you
maintain. You will save me another 10 or so unnended bugreports.
Tomasz
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On Friday 21 October 2005 01:23 pm, Michiel de Bruijne wrote: > On Friday 21 October 2005 04:56, Mike Frysinger wrote: > > On Thursday 20 October 2005 10:49 pm, Dan Meltzer wrote: > > > Why single out this one? ones system will not break irreperbly > > > without a cxx compiler, it'll just cause a another recompile to get it > > > to work after breakage if the person is using -* (which has already > > > been said to be hackish and ill-advised, so doom on them! > > > > it will actually > > > > if you build gcc w/out C++ support that means no libstdc++ > > > > no libstdc++ means python on most boxes is now broken > > > > no python means no emerge > > > > how exactly are you going to re-emerge gcc then ? oh, you cant ... > > Can you think of a situation where this is desired? If not, why not remove > the cxx IUSE and always build the C++-component? i use the flag on my machines with different packages (including gcc) so yes, i can easily think of situations since i use them -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On Friday 21 October 2005 05:56 am, Marius Mauch wrote: > Petteri Räty wrote: > > Every once in a while I see people wanting to use nosomething use flags. > > Why don't we have a package.use like we already have a package.mask > > file? This would make it possible for developers to turn on use flags by > > default in a way that would not cruft the base profiles for every local > > use flag. > > The main problem I'd have with this is the stacking order, e.g. > profiles/package.use has "app-misc/foo bar" and make.conf has > "USE=-bar", which one should be preferred? this is a no brainer profile use.defaults profile package.use profile make.defaults user make.conf user package.use user env -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On Friday 21 October 2005 02:44 am, Harald van Dijk wrote: > On Thu, Oct 20, 2005 at 10:56:57PM -0400, Mike Frysinger wrote: > > On Thursday 20 October 2005 10:49 pm, Dan Meltzer wrote: > > > Why single out this one? ones system will not break irreperbly > > > without a cxx compiler, it'll just cause a another recompile to get it > > > to work after breakage if the person is using -* (which has already > > > been said to be hackish and ill-advised, so doom on them! > > > > it will actually > > > > if you build gcc w/out C++ support that means no libstdc++ > > > > no libstdc++ means python on most boxes is now broken > > > > no python means no emerge > > > > how exactly are you going to re-emerge gcc then ? oh, you cant ... > > It could be handled the same way busybox handles USE=make-symlinks: > simply abort unless the user makes it really clear via an extra variable > that he knows what he's doing. A nocxx flag isn't necessary to protect > users. no, because then it makes it a pita for the people who legitimately use nocxx -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: ${PORTDIR}/profiles/package.use
Duncan wrote: > Put another way... It is said over and over again that USE flags cover > OPTIONAL functionality. Few would consider video/audio/joystick support > in a library with a primary use of supporting games as optional. Rather, > the "option" would be to /not/ have support compiled in, and that's > /exactly/ what the no* USE flags express in this case, just as it's > /exactly/ what the nocxx USE flag expresses. Doing it any other way is, > as stated, counterintuitive to the way portage normally works, and the > defined use of USE flags. > We already have use flags turned on in the base profiles. IMHO we should only have one way of doing this. Either everything should follow the no* convention so we should move to using for example nopython and remove all use flags from make.defaults or implement the requested feature of making use flags on by default. Considering that different profiles probably want different settings the no convention would be restrictive on what we want to do. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On Friday 21 October 2005 04:56, Mike Frysinger wrote: > On Thursday 20 October 2005 10:49 pm, Dan Meltzer wrote: > > Why single out this one? ones system will not break irreperbly > > without a cxx compiler, it'll just cause a another recompile to get it > > to work after breakage if the person is using -* (which has already > > been said to be hackish and ill-advised, so doom on them! > > it will actually > > if you build gcc w/out C++ support that means no libstdc++ > > no libstdc++ means python on most boxes is now broken > > no python means no emerge > > how exactly are you going to re-emerge gcc then ? oh, you cant ... > -mike Can you think of a situation where this is desired? If not, why not remove the cxx IUSE and always build the C++-component? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On Fri, 2005-10-21 at 17:49 +0300, Marius Mauch wrote:
> Petteri Räty wrote:
> > Marius Mauch wrote:
> >
> > Gentoo being about choice the new package.use should come before
> > anything user set. I do not see any problem with this if it works in the
> > same way as package.mask already works. Please, enlighten me.
>
> Because package.use is implemented in a very different way then
> package.mask and currently isn't stackable at all. Adding a
> profiles/package.use that could be overridden by make.conf would require
> some nasty special casing in portage, and as we all know special case
> code is something that should be avoided. Besides that, there would also
> be the question about USE=-*, should this kill profiles/package.use
> completely?
> Short version: Implementation and semantics of profiles/package.use
> isn't much easier than extending IUSE.
>
> Marius
Hijacking this for a moment. And I fully expect to be lynched for the
following but it is something that has come up in both the amd64 and
ppc64 groups in the past.
I know it has been proposed many a time in the past but a per profile
(${PORTDIR}/profiles/default-linux/${ARCH}) package.use.mask would also
come in handy. It's a rare case...but increasingly in the world of mixed
32-bit and 64-bit environments things like java work against 32-bit
stuff *or* 64-bit stuff. This means that the java use flag will work
perfectly on a given arch for one bitness but not the other...and
masking it out completely means that the one bitness where it would work
looses functionality unnecessarily.
Yeah I know this adds a whole additional layer of complexity to the
picture but seeing how DEPEND="!arch? ( use? ( app-foo/bar ) )" is
against policy there has to be some way to control it.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
Petteri Räty wrote: Marius Mauch wrote: Gentoo being about choice the new package.use should come before anything user set. I do not see any problem with this if it works in the same way as package.mask already works. Please, enlighten me. Because package.use is implemented in a very different way then package.mask and currently isn't stackable at all. Adding a profiles/package.use that could be overridden by make.conf would require some nasty special casing in portage, and as we all know special case code is something that should be avoided. Besides that, there would also be the question about USE=-*, should this kill profiles/package.use completely? Short version: Implementation and semantics of profiles/package.use isn't much easier than extending IUSE. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: ${PORTDIR}/profiles/package.use
On Fri, 21 Oct 2005 04:37:16 -0700 Duncan <[EMAIL PROTECTED]> wrote: | Also consider the case of media-libs/libsdl. It uses novideo, | noaudio, and nojoystick, for the simple reason that for the vast | majority of folks who'd have reason to merge the package, turning OFF | that functionality makes entirely NO sense and having it OFF by | default, if the USE flags weren't enabled for some reason, would be | entirely unintuitive. Not a problem. Just turn on the video, audio and joystick USE flags in the base profile. Or don't make them USE flags at all... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpHmPbnTXZEU.pgp Description: PGP signature
[gentoo-dev] Re: ${PORTDIR}/profiles/package.use
Dave Nebinger posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 20 Oct 2005 22:19:13 -0400: >>> > i still dont see how this addresses the nocxx / USE=-* >>> >>> noFOO is used because "FOO" is on by default, and noFOO turns it off. >>> AutoUSE is the same way, package bar is included in the buildplan and to >>> have sane defaults, certain flags are turned on. >> >> that was a great explanation however irrelevant it may have been >> >> i guess we will have to make 'nocxx' a special case as we strip all other >> 'no*' USE flags from portage > > Sorry, guys, but isn't that what "-FOO" is supposed to be for? If we > already have support for "-FOO", why then do we need a "noFOO" also? > > Or is there some distinction I'm missing here? Also consider the case of media-libs/libsdl. It uses novideo, noaudio, and nojoystick, for the simple reason that for the vast majority of folks who'd have reason to merge the package, turning OFF that functionality makes entirely NO sense and having it OFF by default, if the USE flags weren't enabled for some reason, would be entirely unintuitive. Put another way... It is said over and over again that USE flags cover OPTIONAL functionality. Few would consider video/audio/joystick support in a library with a primary use of supporting games as optional. Rather, the "option" would be to /not/ have support compiled in, and that's /exactly/ what the no* USE flags express in this case, just as it's /exactly/ what the nocxx USE flag expresses. Doing it any other way is, as stated, counterintuitive to the way portage normally works, and the defined use of USE flags. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
Marius Mauch wrote: > Petteri Räty wrote: > >> Every once in a while I see people wanting to use nosomething use flags. >> Why don't we have a package.use like we already have a package.mask >> file? This would make it possible for developers to turn on use flags by >> default in a way that would not cruft the base profiles for every local >> use flag. > > > The main problem I'd have with this is the stacking order, e.g. > profiles/package.use has "app-misc/foo bar" and make.conf has > "USE=-bar", which one should be preferred? > Current rules say that /etc/portage/package.use overrides make.conf, and > user config overrides profiles, the proposal would create a new > unintuitive situation between those two. > Depending on the answer on this it also has some technical implications > with the way package.use support is implemented currently. In short it's > not a trivial thing to do. > > Marius Gentoo being about choice the new package.use should come before anything user set. I do not see any problem with this if it works in the same way as package.mask already works. Please, enlighten me. Regards, Petteri Räty signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
Petteri Räty wrote: Every once in a while I see people wanting to use nosomething use flags. Why don't we have a package.use like we already have a package.mask file? This would make it possible for developers to turn on use flags by default in a way that would not cruft the base profiles for every local use flag. The main problem I'd have with this is the stacking order, e.g. profiles/package.use has "app-misc/foo bar" and make.conf has "USE=-bar", which one should be preferred? Current rules say that /etc/portage/package.use overrides make.conf, and user config overrides profiles, the proposal would create a new unintuitive situation between those two. Depending on the answer on this it also has some technical implications with the way package.use support is implemented currently. In short it's not a trivial thing to do. Marius -- gentoo-dev@gentoo.org mailing list
