[gentoo-dev] Detecting gcj in ebuilds

[gentoo-dev] Detecting gcj in ebuilds

[Andrew Cowie]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

Is there a Gentoo Way (tm) for testing whether a specific language
module is available in gcc?

++

The specific case is gcj - I had "gcj" in my use flags from way back,
but I just got a field report from someone testing an ebuild I've
prepared saying:

> it didnt work at first, fell over in the libgtk-java install, but i
> figured out that i had to emerge gcc with gcj support, then I did
> emerge java-gnome and it all worked. Top class. Thanks again.

My ebuilds respond to USE=gcj, but I obviously need to do a dependency
type check. Obviously something like 

	test -x `which gcj`

Would serve, but is there some magic (gcc-config or better yet a
dependency?) which would help?

[It's almost like there should be something like virtual/gcj provided by
gcc if gcc is compiled with Java enabled... Hm]

AfC
Sydney

-- 
Andrew Frederick Cowie
Principal
Operational Dynamics Consulting Pty Ltd

Helping you succeed at flawlessly executing Massive
Changes and Upgrades to your Mission Critical Systems
http://www.operationaldynamics.com/infrastructure/

Sydney   New York   Toronto   London

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Detecting gcj in ebuilds

[Mike Frysinger]

On Wednesday 10 November 2004 06:54 pm, Andrew Cowie wrote:
> Is there a Gentoo Way (tm) for testing whether a specific language
> module is available in gcc?

USE=gcj

> My ebuilds respond to USE=gcj, but I obviously need to do a dependency
> type check. Obviously something like

for now, nothing you can do, just keep utilizing 'USE=gcj'
you want Bug 2272
http://bugs.gentoo.org/show_bug.cgi?id=2272
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Detecting gcj in ebuilds

[Thomas de Grenier de Latour]

On Wed, 10 Nov 2004 18:59:00 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> > My ebuilds respond to USE=gcj, but I obviously need to do a
> > dependency type check. Obviously something like
> 
> for now, nothing you can do, just keep utilizing 'USE=gcj'

app-text/pdftk uses this:

pkg_setup() {
   if [ -z "$(which gcj 2>/dev/null)" ]; then
      eerror "It seems that your system doesn't provides a Java
compiler." 
      eerror "Re-emerge sys-devel/gcc with \"java\" and \"gcj\"
enabled."
      die "gcj not found."
   fi
}

Sure, that doesn't fixes anything, but that's still better than
obscur make failures (and bugreports), no?

> you want Bug 2272

Just by curiosity, what should be the behavior of a Portage
implementing USE dependencies? Failure at depend time? Forcing
a re-emerge of packages with missing flags? Something else?

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Detecting gcj in ebuilds

[Mike Frysinger]

On Wednesday 10 November 2004 07:28 pm, Thomas de Grenier de Latour wrote:
> Just by curiosity, what should be the behavior of a Portage
> implementing USE dependencies? Failure at depend time? Forcing
> a re-emerge of packages with missing flags? Something else?

hasnt been decided ...
i think either forcing a rebuild of the package or failing and telling the 
user what they need to do would be good
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Detecting gcj in ebuilds

[Jason Stubbs]

On Thursday 11 November 2004 09:34, Mike Frysinger wrote:
> On Wednesday 10 November 2004 07:28 pm, Thomas de Grenier de Latour wrote:
> > Just by curiosity, what should be the behavior of a Portage
> > implementing USE dependencies? Failure at depend time? Forcing
> > a re-emerge of packages with missing flags? Something else?
>
> hasnt been decided ...
> i think either forcing a rebuild of the package or failing and telling the
> user what they need to do would be good

I was going with rebuilding the package with the required USE flags. Two 
reasons:

1) Something Mr_Bones_ said - "Emerge should do the least amount of work 
necessary to fulfill a user's request". That seems like a logical statement 
to me. I also interpret that portage should do it if it can as well. I'll go 
into the semantics of what this means in a minute.

2) If we don't do it within portage, there'll be 101 faulty implementations to 
do it automagically in various clients when portage is given a public API. 
Regardless of whether it is our "fault" or not, we'll get the "blame".


So.. semantics. Example time. :)

#1
foo:DEPEND="baz[use]"
baz is installed with -use

"emerge foo" results in:
baz[use]
foo

#2
foo:DEPEND=""
foo:REPEND="baz[use]"
bar:DEPEND="baz[-use]"
bar:RDEPEND=""
baz is installed with -use

"emerge foo bar" or "emerge bar foo" results in:
foo and baz[-use] in parallel/any order
bar

#3
Make DEPENDs into RDEPENDs and vice-versa in the above and..

"emerge foo bar" or "emerge bar foo" results in:
baz[use]
foo and baz[-use] in parallel/any order
bar

#4
foo:DEPEND="baz[use]"
foo:RDEPEND=""
bar:DEPEND="baz[-use]"
bar:RDEPEND=""
baz is installed with -use

"emerge foo bar" or "emerge bar foo" results in:
bar
baz[use]
foo

#5
foo:RDEPEND="baz[use]"
bar:RDEPEND="baz[-use]"

"emerge foo bar" or "emerge bar foo" results in:
NOPE!!!

#6
foo:DEPEND="use? bar[use]"
bar:DEPEND="use? foo[use]"

"emerge foo bar" or "emerge bar foo" results in:
bar
foo[use]
bar[use]
--or--
foo
bar[use]
foo[use]


That last case is interesting. Will probably end up using source size as a 
rough estimate of time to complete in order to determine which package comes 
first. Playing with more than two or three packages gets interesting too...

Anyway, I'm sure most people don't care about this as long as it Just Works, 
so I'll leave the reasoning for going ahead with the merge at that.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Detecting gcj in ebuilds

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]

Hey,

On Thu, 2004-11-11 at 21:57 +0900, Jason Stubbs wrote:
> So.. semantics. Example time. :)
> 
> #1
> foo:DEPEND="baz[use]"
> baz is installed with -use
> 
> "emerge foo" results in:
> baz[use]
> foo

The end result should be baz with the flag matching make.conf
+package.use .. so it should probably be (if the system was consistent
before the merge)...

baz[use]
foo
baz[-use]

Or maybe using a quickpkg like approach to save the pre-existing
baz[-use] 

> #4
> foo:DEPEND="baz[use]"
> foo:RDEPEND=""
> bar:DEPEND="baz[-use]"
> bar:RDEPEND=""
> baz is installed with -use
> 
> "emerge foo bar" or "emerge bar foo" results in:
> bar
> baz[use]
> fooz

Same comment as #1

> #6
> foo:DEPEND="use? bar[use]"
> bar:DEPEND="use? foo[use]"
> 
> "emerge foo bar" or "emerge bar foo" results in:
> bar
> foo[use]
> bar[use]
> --or--
> foo
> bar[use]
> foo[use]

Aren't circular deps forbidden anyway?

#7
foo: RDEPEND=baz[use]
baz is installed -use (because package.use says so)

"emerge foo" says:
NOOO! conflict

#8
same as above with DEPEND

"emerge foo" should probably do:
baz[-use]
foo
baz[use]

Again a quickpkg like approach would become necessary..

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE-based atoms and preference-based USE

[Jason Stubbs]

On Thursday 11 November 2004 22:10, Olivier Crête wrote:
> Hey,

Hi! :)

> On Thu, 2004-11-11 at 21:57 +0900, Jason Stubbs wrote:
> > So.. semantics. Example time. :)
> >
> > #1
> > foo:DEPEND="baz[use]"
> > baz is installed with -use
> >
> > "emerge foo" results in:
> > baz[use]
> > foo

On Thursday 11 November 2004 22:10, Olivier Crête wrote:
> The end result should be baz with the flag matching make.conf
> +package.use .. so it should probably be (if the system was consistent
> before the merge)...
>
> baz[use]
> foo
> baz[-use]
>
> Or maybe using a quickpkg like approach to save the pre-existing
> baz[-use]

Yep, that sounds good on all counts.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Detecting gcj in ebuilds

[Thomas de Grenier de Latour]

On Thu, 11 Nov 2004 21:57:41 +0900
Jason Stubbs <jstubbs@gentoo.org> wrote:

> 1) Something Mr_Bones_ said - "Emerge should do the least amount
> of work necessary to fulfill a user's request". That seems like
> a logical statement to me. I also interpret that portage should
> do it if it can as well.

That seems logical, but sometimes warning the user that his
request is stupid may be better for him. I mean, if emerging a
fortran program implies two gcc merges, and then emerging another
fortran program implies again two more gcc merges, etc., i think
the user will not be that happy of having been blindly obeyed.

With the "failure at depend time" approach, what would happen is
that the user would have to change is USE flags, re-emerge gcc
once for all, and then he would be able to emerge as many fortran
programs he wants. And his system would also stay consistent. That
is, thanks to the human intervention it requires, a much smarter
overall process imho.

> Example time. :)

I think it may help to also look at real world examples. As a
beginning, a quick grep on "re-emerge" in current tree gives me:

- sys-devel/gcc[gcj], sys-devel/gcc[java]
Both DEPEND and RDEPEND (apps link to libgcj.so), despite it is
implicit since it is a system package.
Example: app-text/pdftk

- sys-devel/gcc[fortran], sys-devel/gcc[f77], sys-devel/gcc[g77]
(doh! Did the USE flag name really changed that often?)
I think it is a DEPEND only, so this one fall into your #1
example.
Example: app-sci/molden

- sys-devel/gcc[multilib]
Both DEPEND and RDEPEND.
Example: games-emulation/zsnes

- dev-python/gnome-python[gtkhtml]
RDEPEND only.
Example: media-sound/solfege

- x11-libs/wxGTK[-unicode]
Both DEPEND and RDEPEND.
Example: media-sound/freqtweak

- media-libs/gd[jpeg]
Both DEPEND and RDEPEND.
Example: app-admin/analog

- x11-libs/qt[mysql]
Both DEPEND and RDEPEND.
Example: media-tv/mythfrontend

- dev-dotnet/gtk-sharp[gnome]
Both DEPEND and RDEPEND.
Example: dev-dotnet/gtksourceview-sharp

- dev-dotnet/gtk-sharp[gtkhtml]
Both DEPEND and RDEPEND.
Example: dev-util/monodoc

- media-libs/imlib2[X]
Both DEPEND and RDEPEND.
Example: media-libs/giblib

- dev-php/php[session], dev-php/mod_php[session]
Both DEPEND and RDEPEND.
Example: www-apps/mythweb

This list is for sure not complete, but what we can see is that in
most cases, this deps are at least RDEPEND deps. That means that
if we want emerge to preserve system consistency (installed
packages respect make.conf+package.use flags), there is nothing
clever to do for emerge, but to fail at depend time and ask the
user to change his flags and re-emerge some packages (that is
Olivier's example #7).

The only exception is g77, but i think "fortran" is a default USE
flag in most profiles, no? So there should not be that many users
missing that compiler, and if there are any, my opinion is that
they will prefer to have a bit of manual work to do than to look
emerge reinstalling gcc several times.

So my opinion is that, _so far_, there seems to be no real need
for the clever solution you've proposed, and that the simpler
check and failure approach would be enough. But sure, that may not
be true anymore in the future (or with some packages that i've
missed).

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Detecting gcj in ebuilds

[Jason Stubbs]

On Friday 12 November 2004 01:04, Thomas de Grenier de Latour wrote:
> On Thu, 11 Nov 2004 21:57:41 +0900
>
> Jason Stubbs <jstubbs@gentoo.org> wrote:
> > 1) Something Mr_Bones_ said - "Emerge should do the least amount
> > of work necessary to fulfill a user's request". That seems like
> > a logical statement to me. I also interpret that portage should
> > do it if it can as well.
>
> That seems logical, but sometimes warning the user that his
> request is stupid may be better for him. I mean, if emerging a
> fortran program implies two gcc merges, and then emerging another
> fortran program implies again two more gcc merges, etc., i think
> the user will not be that happy of having been blindly obeyed.

emerge --pretend will always show what emerge is going to do.

> > Example time. :)
>
> I think it may help to also look at real world examples. As a
> beginning, a quick grep on "re-emerge" in current tree gives me:
<SNIP>
> that in most cases, this deps are at least RDEPEND deps. That means that if 
> we want emerge to preserve system consistency (installed packages respect 
> make.conf+package.use flags), there is nothing clever to do for emerge, but 
> to fail at depend time and ask the user to change his flags and re-emerge 
> some packages (that is Olivier's example #7).    
>
> So my opinion is that, _so far_, there seems to be no real need
> for the clever solution you've proposed, and that the simpler
> check and failure approach would be enough. But sure, that may not
> be true anymore in the future (or with some packages that i've
> missed).

unixODBC-2.2.8.ebuild:DEPEND="qt? ( >=x11-libs/qt-3.0* )"
qt-3.3.3-r1.ebuild:DEPEND="odbc? ( dev-db/unixODBC )"

Don't let that '*' in unixODBC's DEPEND confuse you - that's somebody's 
misunderstanding and should be written as >=x11-libs/qt-3. This is one case 
that already exists in the tree and I'm certain that there are others. Even 
if there were no existing cases at present, not implementing it from the 
start is just a guaranteed bug. If the dep resolver has to be rewritten 
anyway, why not bring it up to scratch?

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Detecting gcj in ebuilds

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

On Friday 12 November 2004 15:20, Jason Stubbs wrote:
> unixODBC-2.2.8.ebuild:DEPEND="qt? ( >=x11-libs/qt-3.0* )"
> qt-3.3.3-r1.ebuild:DEPEND="odbc? ( dev-db/unixODBC )"

Uh, I just wanted to note that there's an ebuild-land solution to this in the 
new dev-db/qt-unixODBC ebuild. It splits out the odbc-dependant part of QT 
into a separate ebuild. Cf. bug 14178.

Shameless plug: I NEED testers for that! If you care about the qt-odbc dep 
loop, please visit bug 14178!

This isn't a comment on the general discussion here, but please choose another 
example :-)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Detecting gcj in ebuilds

[Thomas de Grenier de Latour]

On Fri, 12 Nov 2004 22:20:29 +0900
Jason Stubbs <jstubbs@gentoo.org> wrote:

> emerge --pretend will always show what emerge is going to do.

Sure, but you know how users are. Until .51, many users complained
about emerge that was marking "N" for slotted packages, that was
upgrading some injected packages, that was insisting to install
things because they were referenced in edb/virtuals, etc.
Everytime emerge's behavior goes a bit counter-intuitive, many
users are lost. And i think that seeing gcc re-emerged several
times on a world update will be counter-intuitive for many of
them. I agree that your approach is the right thing to do from a
reasonable semantics point of view, but from a user point of view
it will probably look different. 
  That said, this problem can also be solved by some cosmetic
means, like adding a big warning of that kind:
 * gcc will have to be emerged twice because you lack the fortran
 * USE flag, so if that is a problem for you, then add this flag
 * and you'll be fine. 10 9 8 7 6 5 4 3 2 1

> Even if there were no existing cases at present, not
> implementing it from the start is just a guaranteed bug. If the
> dep resolver has to be rewritten anyway, why not bring it up to
> scratch?

I completly agree on that, if things are rewrote from scratch,
there is no reason to re-introduce some known limitations that can
be avoided. 

My point was more that the "check and failure" approach is also
an acceptable short term solution, considering that it does not
need a complete rewrite of the deps solver, and will give similar
results (conflict/failure at depend time) on most existing cases.
Does it worth being implemented? I don't know, it depends what are
the plans for (or what is the status of) the deps solver
rewriting. If it is supposed to come in the next few months, then
i guess that this issue can just wait a bit more.

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Detecting gcj in ebuilds

[Duncan]

Thomas de Grenier de Latour posted
<20041112152916.348abb9e.degrenier@easyconnect.fr>, excerpted below,  on
Fri, 12 Nov 2004 15:29:16 +0100:

> On Fri, 12 Nov 2004 22:20:29 +0900
> Jason Stubbs <jstubbs@gentoo.org> wrote:
> 
>> emerge --pretend will always show what emerge is going to do.
> 
> Sure, but you know how users are.[] I agree that your approach is the
> right thing to do from a reasonable semantics point of view, but from a
> user point of view it will probably look different.
>   That said, this problem can also be solved by some cosmetic
> means, like adding a big warning of that kind:
>  * gcc will have to be emerged twice because you lack the fortran * USE
>  flag, so if that is a problem for you, then add this flag * and you'll
>  be fine. 10 9 8 7 6 5 4 3 2 1

OK, I'm one of those "users".  Read that as sysadmin of a Gentoo system.
Sysadmin carries some responsibility for knowing how the system is set up,
particularly as it pertains to security issues.  I don't take that
responsibility lightly, nor would I expect anyone to seriously recommend
that I do so.

I would **NOT** appreciate portage taking upon ITSELF to CHANGE my USE
flags behind my back!!!  Count this as one vote for emerge-stopping
errors, NOT warnings that may or may not be seen in the middle of a string
of emerges.  Yes, I use pretend (or more generally, ask), and would
normally catch a repeated emerge there.  However, I still don't want use
flags being changed out from under me.

Of course, as already mentioned repeatedly, having a depend resolution
time failure would be better than EITHER that warning or failure after a
string of depends have been merged.  I agree there (what's not to agree
with?).  However, regardless of whether that's possible, if a use flag
needs changed, I want an error spit out to that effect, so **I** get to
decide whether to change it or try some other package that doesn't require
changes in my use flags.  I do NOT want it simply changed, at the whim of
portage, regardless of whether there's a big warning before it happens. 
If a use flag needs changed, *I* want to be the one changing it, on *MY*
system.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Detecting gcj in ebuilds

[Ed Grimm]

On Tue, 16 Nov 2004, Duncan wrote:

<snip>
> I would **NOT** appreciate portage taking upon ITSELF to CHANGE my USE
> flags behind my back!!!  Count this as one vote for emerge-stopping
> errors, NOT warnings that may or may not be seen in the middle of a string
> of emerges.  Yes, I use pretend (or more generally, ask), and would
> normally catch a repeated emerge there.  However, I still don't want use
> flags being changed out from under me.
>
> Of course, as already mentioned repeatedly, having a depend resolution
> time failure would be better than EITHER that warning or failure after a
> string of depends have been merged.  I agree there (what's not to agree
> with?).  However, regardless of whether that's possible, if a use flag
> needs changed, I want an error spit out to that effect, so **I** get to
> decide whether to change it or try some other package that doesn't require
> changes in my use flags.  I do NOT want it simply changed, at the whim of
> portage, regardless of whether there's a big warning before it happens.
> If a use flag needs changed, *I* want to be the one changing it, on *MY*
> system.

Agreed.  If I have specified a USE flag of -<lang>, there may be a
reason.  Given that there's no easy way to tell emerge sync to not pull
down any ebuilds that depend on <lang>, and to not pull down any ebuilds
that depend on an ebuild that depends on <lang> (, yada yada), It's very
easy for me to make a mistake, and select a package that is written in
<lang>.  That doesn't mean I want it.

Ed

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Detecting gcj in ebuilds

[Luke-Jr]

On Wednesday 17 November 2004 2:57 am, Duncan wrote:
> Thomas de Grenier de Latour posted
> <20041112152916.348abb9e.degrenier@easyconnect.fr>, excerpted below,  on
>
> Fri, 12 Nov 2004 15:29:16 +0100:
> > On Fri, 12 Nov 2004 22:20:29 +0900
> >
> > Jason Stubbs <jstubbs@gentoo.org> wrote:
> >> emerge --pretend will always show what emerge is going to do.
> >
> > Sure, but you know how users are.[] I agree that your approach is the
> > right thing to do from a reasonable semantics point of view, but from a
> > user point of view it will probably look different.
> >   That said, this problem can also be solved by some cosmetic
> > means, like adding a big warning of that kind:
> >  * gcc will have to be emerged twice because you lack the fortran * USE
> >  flag, so if that is a problem for you, then add this flag * and you'll
> >  be fine. 10 9 8 7 6 5 4 3 2 1
>
> OK, I'm one of those "users".  Read that as sysadmin of a Gentoo system.
> Sysadmin carries some responsibility for knowing how the system is set up,
> particularly as it pertains to security issues.  I don't take that
> responsibility lightly, nor would I expect anyone to seriously recommend
> that I do so.
>
> I would **NOT** appreciate portage taking upon ITSELF to CHANGE my USE
> flags behind my back!!!  Count this as one vote for emerge-stopping
> errors, NOT warnings that may or may not be seen in the middle of a string
> of emerges.  Yes, I use pretend (or more generally, ask), and would
> normally catch a repeated emerge there.  However, I still don't want use
> flags being changed out from under me.

This would be not very different than GNOME forcing you to emerge GTK despite 
having -gtk in your USE...
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Detecting gcj in ebuilds

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On Wednesday 17 November 2004 05:44, Luke-Jr wrote:
>
> This would be not very different than GNOME forcing you to emerge GTK
> despite having -gtk in your USE...

Agreed, that's why we have a pretend option for emerge. I for one never go 
without it. I want to know what portage is going to be doing before it 
does it.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Detecting gcj in ebuilds

[Andrew Cowie]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

On Wed, 2004-17-11 at 14:39 +0100, Paul de Vrieze wrote:
> I want to know what portage is going to be doing before it 
> does it.

Right (I don't think that anyone disagrees with you here). The thing
[that this thread is] trying to figure out, though, is this:

I need to be able to express, in the dependencies of an ebuild, that I
require gcc to have been compiled with a certain USE flag, a capability
that portage doesn't [yet] provide.

The consensus of the best thing to do as an immediate work around is to
write some code early on in your ebuild which evaluates whether or not
the dependency was actually built under the needed USE conditions, and
to fail with a message informing what the user must do about it if they
choose to proceed.

The problem with that of course is that you may well end up building a
huge number of dependencies before you get to your ebuild which will
then have to fail out to the user saying "sorry, you need to go and
rebuild gcc with this USE flag set".

So that's where we're at. 

AfC
Atlanta

-- 
Andrew Frederick Cowie
Principal
Operational Dynamics Consulting Pty Ltd

Helping you succeed at flawlessly executing Massive
Changes and Upgrades to your Mission Critical Systems
http://www.operationaldynamics.com/services/procedures/

Sydney   New York   Toronto   London

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Detecting gcj in ebuilds

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

On Wednesday 17 November 2004 18:02, Andrew Cowie wrote:
> On Wed, 2004-17-11 at 14:39 +0100, Paul de Vrieze wrote:
> > I want to know what portage is going to be doing before it
> > does it.
>
> Right (I don't think that anyone disagrees with you here). The thing
> [that this thread is] trying to figure out, though, is this:
>
> I need to be able to express, in the dependencies of an ebuild, that I
> require gcc to have been compiled with a certain USE flag, a capability
> that portage doesn't [yet] provide.
>
> The consensus of the best thing to do as an immediate work around is to
> write some code early on in your ebuild which evaluates whether or not
> the dependency was actually built under the needed USE conditions, and
> to fail with a message informing what the user must do about it if they
> choose to proceed.
>
> The problem with that of course is that you may well end up building a
> huge number of dependencies before you get to your ebuild which will
> then have to fail out to the user saying "sorry, you need to go and
> rebuild gcc with this USE flag set".

I understand this issue, and think useflag deps should be added fast as 
they are needed. In the meantime it might be easier to introduce some 
kind of function (like pkg_prebuild) that can perform checks before the 
actual merging of dependencies, but after the building of the dependency 
tree.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Detecting gcj in ebuilds

[Jason Stubbs]

On Tue, 16 Nov 2004, Duncan wrote:
> I would **NOT** appreciate portage taking upon ITSELF to CHANGE my USE
> flags behind my back!!!  Count this as one vote for emerge-stopping
> errors, NOT warnings that may or may not be seen in the middle of a
> string of emerges.  Yes, I use pretend (or more generally, ask), and
> would normally catch a repeated emerge there.  However, I still don't
> want use flags being changed out from under me.
>
> Of course, as already mentioned repeatedly, having a depend resolution
> time failure would be better than EITHER that warning or failure after a
> string of depends have been merged.  I agree there (what's not to agree
> with?).  However, regardless of whether that's possible, if a use flag
> needs changed, I want an error spit out to that effect, so **I** get to
> decide whether to change it or try some other package that doesn't
> require changes in my use flags.  I do NOT want it simply changed, at the
> whim of portage, regardless of whether there's a big warning before it
> happens. If a use flag needs changed, *I* want to be the one changing it,
> on *MY* system.

Take your indignance somewhere else please.

On Wednesday 17 November 2004 12:38, Ed Grimm wrote:
> Agreed.  If I have specified a USE flag of -<lang>, there may be a
> reason.  Given that there's no easy way to tell emerge sync to not pull
> down any ebuilds that depend on <lang>, and to not pull down any ebuilds
> that depend on an ebuild that depends on <lang> (, yada yada), It's very
> easy for me to make a mistake, and select a package that is written in
> <lang>.  That doesn't mean I want it.

If you read Olivier Crête's reply more closely, you'll see that he stated 
exactly the same thing and that I already ack'ed it.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Detecting gcj in ebuilds

[Duncan]

Luke-Jr posted <200411170444.23945.luke-jr@utopios.org>, excerpted below, 
on Wed, 17 Nov 2004 04:44:23 +0000:

> On Wednesday 17 November 2004 2:57 am, Duncan wrote:
>>
>> I would **NOT** appreciate portage taking upon ITSELF to CHANGE my USE
>> flags behind my back!!!  Count this as one vote for emerge-stopping
>> errors, NOT warnings that may or may not be seen in the middle of a
>> string of emerges.  Yes, I use pretend (or more generally, ask), and
>> would normally catch a repeated emerge there.  However, I still don't
>> want use flags being changed out from under me.
> 
> This would be not very different than GNOME forcing you to emerge GTK
> despite having -gtk in your USE...

Quite the contrary.  I'd suggest it's VERY different, both conceptually
and in practice.

Conceptually, remember that USE flags ARE NOT intended to affect
REQUIREMENTS, only OPTIONS.  Thus, -gtk doesn't mean that emerging Gnome
will fail even tho it requires gtk, ONLY that any packages that (for
instance) may use gtk or qt libs will be built without the gtk support.

Thus, your example has gtk as a dependency of gnome and quite naturally
ignores the gtk use flag since it's a requirement, while the example of
the thread is NOT ignoring use flags, but CHANGING them for a specific
rebuild dependency.  The parallel to gtk/gnome in the thread situation
would be if there was a separate gcj package that was required for the
ebuild in question, that could then be made a dependency.  That's
conceptually quite different from changing the use flags on an existing
merged package.

Practically, the difference is one of time, forcing a remerge of an
otherwise perfectly workable existing package, vs. simply requiring it,
using the existing package if there, forcing an emerge ONLY if not. 
(That's the minimum, plus possibly an additional binary packaging of the
existing installation before the remerge, and remerge of it replacing the
modified package afterward.)

As I said, this is VERY different than a simple dependency based forced
emerge.  A simple dependency based forced emerge can be expected and
should be covered by an emerge pretend or an emerge ask.  Ignoring
Gentoo user's (meaning Gentoo installation sysadmin's) stated OPTION
requests, arbitrarily reversing them without specific action on said
sysadmin's part, is an ENTIRELY different thing.  Among other things, it's
begging for additional security issues because the admin had no logical
reason to think he had anything installed that was affected, when he did. 
That's in addition to the issues of usurping control from the admin,
thinking you know better than he does what should happen on his system. 
IMO, that's something MS does, not something Gentoo should be doing.

As for dependency-time checks, great!  I'm all for getting a warning
before I've emerged all those pre-merge dependencies, after suitable
functionality has been coded into portage to support that.  Regardless of
whether that functionality is there or not, however, as a Gentoo user aka
sysadmin of a Gentoo system, one that takes that sysadmin and
security-admin job seriously, I'm opposed to changing use flags behind my
back.  Error out with an appropriate message if necessary, even if it's
AFTER a bunch of dependencies have been installed if there's no way to do
it earlier. I'll either fix the problem and rerun the emerge, or I'll do
an emerge --depclean and clean out all the gunk I now can't use.  However,
it'll remain MY decision, in either case.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Detecting gcj in ebuilds

[Jason Stubbs]

土曜日 20 11月 2004 15:13、Duncan さんは書きました:
> Luke-Jr posted <200411170444.23945.luke-jr@utopios.org>, excerpted below,
>
> on Wed, 17 Nov 2004 04:44:23 +0000:
> > On Wednesday 17 November 2004 2:57 am, Duncan wrote:
> >> I would **NOT** appreciate portage taking upon ITSELF to CHANGE my USE
> >> flags behind my back!!!  Count this as one vote for emerge-stopping
> >> errors, NOT warnings that may or may not be seen in the middle of a
> >> string of emerges.  Yes, I use pretend (or more generally, ask), and
> >> would normally catch a repeated emerge there.  However, I still don't
> >> want use flags being changed out from under me.

Commented no this already.

> > This would be not very different than GNOME forcing you to emerge GTK
> > despite having -gtk in your USE...

I agree with this.

> Quite the contrary.

<snip 5 sentences with misuse of capitals>

> The parallel to gtk/gnome in the thread situation would be if there was a 
> separate gcj package that was required for the ebuild in question, that 
> could then be made a dependency.  That's conceptually quite different from 
> changing the use flags on an existing merged package.   

Is it conceptually different from changing the USE flags on a package that 
hasn't been merged yet?

<snip 1 sentence with misuse of capitals>

> (That's the minimum, plus possibly an additional binary packaging of the
> existing installation before the remerge, and remerge of it replacing the
> modified package afterward.)

I don't understand the context here after cutting out your yelling.

<snip 1 sentence with misuse of capitals>

> A simple dependency based forced emerge can be expected and
> should be covered by an emerge pretend or an emerge ask.

I don't know about you, but I think that a package requiring certain 
capabilities of another package fits in completely with the definition of 
"simple dependency".

<snip 1 sentence with misuse of capitals>

> Among other things, it's begging for additional security issues because the 
> admin had no logical reason to think he had anything installed that was 
> affected, when he did. That's in addition to the issues of usurping control 
> from the admin, thinking you know better than he does what should happen on 
> his system. IMO, that's something MS does, not something Gentoo should be 
> doing.     

This is just fud. What would be "usurping control" and blah blah blah would be 
to remove the gcj flag from gcc and just force it to be compiled. That would 
solve this as well and would actually be much easier to implement. Yeah, 
let's do it! It'd save me and many others a load of time.

> As for dependency-time checks, great!  I'm all for getting a warning
> before I've emerged all those pre-merge dependencies, after suitable
> functionality has been coded into portage to support that.  Regardless of
> whether that functionality is there or not, however, as a Gentoo user aka
> sysadmin of a Gentoo system, one that takes that sysadmin and
> security-admin job seriously, I'm opposed to changing use flags behind my
> back.  

Heh.. "behind my back". Aren't you already aware of what's going on?

<snip 1 sentence with misuse of capitals>

> I'll either fix the problem and rerun the emerge, or I'll do an emerge 
> --depclean and clean out all the gunk I now can't use.   

<snip 1 sentence with misuse of capitals>

--depclean is broken. Packages dying several hours into an emerge is pretty 
broken behaviour as well. Are you not just afraid of change?

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Detecting gcj in ebuilds

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On Saturday 20 November 2004 07:13, Duncan wrote:
> Conceptually, remember that USE flags ARE NOT intended to affect
> REQUIREMENTS, only OPTIONS.  Thus, -gtk doesn't mean that emerging Gnome
> will fail even tho it requires gtk, ONLY that any packages that (for
> instance) may use gtk or qt libs will be built without the gtk support.

If you want to make sure that gtk never gets merged, you have a very simple 
option. You add it to /etc/portage/package.mask, and portage will complain 
with every package that needs/wants it.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]