[gentoo-dev] Portage suggestion

[gentoo-dev] Portage suggestion

[Mezei Zoltan]

Hi!

Is there a way to do something like this:
want to emerge programs A and B
portage downloads A
portage compiles A and at he same time portage downloads B
when compilation of A finishes, portage compiles B
That would be a great feature...

Is is possible?

Zizi

Re: [gentoo-dev] Portage suggestion

[Dan Naumov]

Submit this suggestion to Gentoo BugZilla.

Dan "Jago" Naumov


On 13 Aug 2002 16:44:16 +0200
Mezei Zoltan <mz269@ural2.hszk.bme.hu> wrote:

> Hi!
> 
> Is there a way to do something like this:
> want to emerge programs A and B
> portage downloads A
> portage compiles A and at he same time portage downloads B
> when compilation of A finishes, portage compiles B
> That would be a great feature...
> 
> Is is possible?
> 
> Zizi

Re: [gentoo-dev] Portage suggestion

[Mezei Zoltan]

Hi!

On Tue, 13 Aug 2002, Dan Naumov wrote:
> Submit this suggestion to Gentoo BugZilla.
OK, I did. How long time can it take to develop and commit such a feature
to the main portage tree?

Zizi

Re: [gentoo-dev] Portage suggestion

[Hannes Mehnert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

look at http://bugs.gentoo.org/show_bug.cgi?id=1661

On Tue, Aug 13, 2002 at 06:09:59PM +0300, Dan Naumov wrote:
> Submit this suggestion to Gentoo BugZilla.
> 
> > Is there a way to do something like this:
> > want to emerge programs A and B
> > portage downloads A
> > portage compiles A and at he same time portage downloads B
> > when compilation of A finishes, portage compiles B
> > That would be a great feature...
> > 
> > Is is possible?

Hannes Mehnert

GPG-Fingerprint: B3BB E539 F6BF 6942 1492  3ACF 45CB 8D97 3881 8D1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9WSVdRcuNlziBjRwRAldzAJwNdeYzHjV2PP9Dsj0N74d6XEq5TgCfdfex
8pvbh4nhDL5Ge2+xfqlrGr4=
=B2N+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage suggestion

[Thomas T. Veldhouse]

I think what the original poster is looking for is the ability for it to
fetch in the background and compile in the foreground.  Time to compile
meta-packages like KDE might be reduced significantly, especially on
bandwidth challenged systems.  Basically, the fetch should be performed on a
separate thread than the build.

Tom Veldhouse

----- Original Message -----
From: "Christian Skarby" <christian.skarby@interhost.no>
To: <gentoo-dev@gentoo.org>
Cc: <mz269@hszk.bme.hu>
Sent: Tuesday, August 13, 2002 11:11 AM
Subject: Re: [gentoo-dev] Portage suggestion


> I belive it could be achieved by doing this:
>
> emerge --fetchonly A B && emerge A B
> or
> emerge -f A B && emerge A B
> for short
>
> Even though it would be nice to have a flag like --fetchfirst (so that one
> do not need to list the ebuilds twice, I still think the portage-system
> will have to go through it twice.)
>
> BTW what is the id-bug-number of your bug?
> (I believe that it would be nice if we post that as a reference in
> situations like this.)
>
> All the best,
> Christian
>
> > Hi!
> >
> > On Tue, 13 Aug 2002, Dan Naumov wrote:
> >> Submit this suggestion to Gentoo BugZilla.
> > OK, I did. How long time can it take to develop and commit such a
> > feature to the main portage tree?
> >
> > Zizi
> >
> >
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@gentoo.org
> > http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>
>
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>

Re: [gentoo-dev] Portage suggestion

[Christian Skarby]

I belive it could be achieved by doing this:

emerge --fetchonly A B && emerge A B
or
emerge -f A B && emerge A B
for short

Even though it would be nice to have a flag like --fetchfirst (so that one
do not need to list the ebuilds twice, I still think the portage-system
will have to go through it twice.)

BTW what is the id-bug-number of your bug?
(I believe that it would be nice if we post that as a reference in
situations like this.)

All the best,
Christian

> Hi!
>
> On Tue, 13 Aug 2002, Dan Naumov wrote:
>> Submit this suggestion to Gentoo BugZilla.
> OK, I did. How long time can it take to develop and commit such a
> feature to the main portage tree?
>
> Zizi
>
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] Portage suggestion

[Christian Skarby]

Sorry about not reading the initial mail twice,
what you really wanted were that portage should start to compile
A as soon as it has what that is required, and download B (and possibly C)
while it start to, and compiles A. What I've suggested will not do that.

=)

Christian

> I belive it could be achieved by doing this:
>
> emerge --fetchonly A B && emerge A B
> or
> emerge -f A B && emerge A B
> for short
>
> Even though it would be nice to have a flag like --fetchfirst (so that
> one do not need to list the ebuilds twice, I still think the
> portage-system will have to go through it twice.)
>
> BTW what is the id-bug-number of your bug?
> (I believe that it would be nice if we post that as a reference in
> situations like this.)
>
> All the best,
> Christian
>
>> Hi!
>>
>> On Tue, 13 Aug 2002, Dan Naumov wrote:
>>> Submit this suggestion to Gentoo BugZilla.
>> OK, I did. How long time can it take to develop and commit such a
>> feature to the main portage tree?
>>
>> Zizi
>>
>>
>> _______________________________________________
>> gentoo-dev mailing list
>> gentoo-dev@gentoo.org
>> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>
>
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] Portage suggestion

[Charles Lacour]

On Tuesday 13 August 2002 11:10, Thomas T. Veldhouse wrote:
> I think what the original poster is looking for is the ability for it to
> fetch in the background and compile in the foreground.  Time to compile
> meta-packages like KDE might be reduced significantly, especially on
> bandwidth challenged systems.  Basically, the fetch should be performed on
> a separate thread than the build.
>
> Tom Veldhouse

That's the way I read it, too, and I'm fairly sure there's something that 
does exactly that in beta-testing right now.

Ok, I found it. It was posted by Nick Jones <carpaski@gentoo.org> on Aug 3, 
2002, with a subject of "Concurrent download and merge"

In case you have trouble finding it for whatever reason, here's the text:




I've been working on code to make downloading occur continuously
during the emerge process. I have new, clean, and working code
that needs a bit more testing that I can give it. I'd appreciate
some testing. It includes a couple subtle enhancements also. Try
'emerge -ef world' to see the "(X of Y)" counts.

At present, the output is a little noisy because wget and builds
are happening at the same time. I HIGHLY recommend adding "-q"
to wget's FETCH_COMMAND in make.globals/make.conf.

Please CC me (carpaski@gentoo.org) with any bugs that you think
you come across. PLEASE follow the directions in the README.txt.

http://gentoo.twobit.net/portage/threaded/

It does as follows:

1. Downloads begin and do not pause until they are completed.
2. Merges occur in order as the required files finish downloading.
3. Failed merges will stop the merging of packages at that point,
   but fetching will continue until all files are downloaded.
4. Failed fetches will be announced, but WILL NOT stop the fetching.
   Merges will continue until the failed fetch is reached. Fetches
   will continue until all fetches have completed.
5. Failures in the fetching and/or failure in the merge will be
   noted when both the fetching and the merging are completed.
   Only one notice for the fetches is given. Only one notice
   of the failed merge is given.

Thanks,
-- Nicholas Jones

[gentoo-dev] portage suggestion

[Jean-Francois Patenaude]

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


Related to this comment in the emerge manpage:

--update (-u)
	Updates packages to the most recent version available.	Note that
	--update does not have	full functionality  yet.   It  will  not
	automatically update dependencies of packages in the world file,
	unless they too are in the world file.

I created a kind of "emerge --update universe" that you can find
in the attached patch.  Comments are welcome !

The patch applies over portage 2.0.45-r5
md5sum of the original emerge: 7eb429e274ff9713270b1a7b3649c22e

Jf.

[-- Attachment #2: Type: text/plain, Size: 5203 bytes --]

--- emerge	2002-12-13 19:15:34.000000000 -0500
+++ emerge-universe	2002-12-15 12:58:00.000000000 -0500
@@ -14,7 +14,7 @@
 #number of ebuilds merged
 merged=0
 params=["selective", "deep", "self", "recurse", "empty"]
-actions=["clean", "config", "help", "info", "prune", "rsync", "search", "sync", "system", "unmerge", "world", "inject", "regen", "depclean"]
+actions=["clean", "config", "help", "info", "prune", "rsync", "search", "sync", "system", "unmerge", "world", "universe", "inject", "regen", "depclean"]
 options=["--autoclean", "--deep", "--selective", "--buildpkg", "--debug", "--nodeps", "--emptytree", "--fetchonly", 
 "--noreplace", "--onlydeps", "--pretend", "--usepkg", "--usepkgonly", "--searchdesc", "--verbose", "--update", "--help", "--oneshot", "--version"]
 
@@ -82,6 +82,7 @@
 		print "              Cleans the system by removing outdated packages which will not"
 		print "              remove functionalities or prevent your system from working."
 		print "              The arguments can be in several different formats :"
+		print "              * universe "
 		print "              * world "
 		print "              * system "
 		print "              * /var/db/pkg/category/package-version, or"
@@ -351,8 +352,8 @@
 	else:
 		myfiles.append(x)
 
-if (myaction in ["world", "system"]) and myfiles:
-	print "emerge: please specify a package class (\"world\" or \"system\") or individual packages, but not both."
+if (myaction in ["universe", "world", "system"]) and myfiles:
+	print "emerge: please specify a package class (\"universe\", \"world\" or \"system\") or individual packages, but not both."
 	sys.exit(1)
 
 # Always create packages if FEATURES=buildpkg
@@ -384,7 +385,7 @@
 		pass
 	elif (not myaction) and (not myfiles):
 		pass
-	elif ("--pretend" in myopts) and (myaction in ["world","system","clean","prune","unmerge"]):
+	elif ("--pretend" in myopts) and (myaction in ["universe", "world","system","clean","prune","unmerge"]):
 		pass
 	else:
 		print "myaction",myaction
@@ -420,7 +421,7 @@
 	add.extend(["deep"])
 if "--selective" in myopts:
 	add.extend(["selective"])
-if myaction in ["world","system"]:
+if myaction in ["universe", "world","system"]:
 	add.extend(["selective"])
 elif myaction in ["depclean"]:
 	sub.extend(["selective"])
@@ -597,6 +598,8 @@
 			sys.exit(1)
 	elif mode=="world":
 		pfile=portage.root+"var/cache/edb/world"
+	elif mode=="universe":
+		pfile=portage.root+"var/cache/edb/universe"
 	try:
 		myfile=open(pfile,"r")
 		mylines=myfile.readlines()
@@ -895,6 +898,27 @@
 		global syslist
 		if mode=="system":
 			mylist=syslist
+		elif mode=="universe":
+			#universe mode
+			universelist=getlist("universe")
+			sysdict=genericdict(syslist)
+			universedict=genericdict(universelist)
+			#we're effectively upgrading sysdict to contain all new deps from universedict
+			for x in universedict.keys():
+				#only add the universe node if the package is:
+				#actually installed -- this prevents the remerging of already unmerged packages when we do a universe --update;
+				#actually available -- this prevents emerge from bombing out due to no match being found (we want a silent ignore)
+				if "empty" in myparams:
+					if portage.db["/"]["vartree"].dbapi.match(x):
+						sysdict[x]=universedict[x]
+				elif portage.db[portage.root]["vartree"].dbapi.match(x):
+					#package is installed
+					sysdict[x]=universedict[x]
+				else:
+					print "\n*** Package in universe file is not installed: "+x
+			mylist=[]
+			for x in sysdict.keys():
+				mylist.append(sysdict[x])
 		else:
 			#world mode
 			worldlist=getlist("world")
@@ -1151,11 +1175,11 @@
 	candidate_catpkgs=[]
 	global_unmerge=0
 	
-	if not unmerge_files or "world" in unmerge_files or "system" in unmerge_files:
+	if not unmerge_files or "world" in unmerge_files or "system" in unmerge_files or "universe" in unmerge_files:
 		if "unmerge"==unmerge_action:
 			print
 			print bold("emerge unmerge")+" can only be used with specific package names, not with "+bold("world")+" or"
-			print bold("system")+" targets."
+			print bold("system")+" or "+bold("universe")+" targets."
 			print
 			return 0
 		else:
@@ -1164,7 +1188,7 @@
 	localtree=portage.db[portage.root]["vartree"]
 	# process all arguments and add all valid db entries to candidate_catpkgs
 	if global_unmerge:
-		if not unmerge_files or "world" in unmerge_files:
+		if not unmerge_files or "world" in unmerge_files or "universe" in unmerge_files:
 			candidate_catpkgs.extend(localtree.getallnodes())	
 		elif "system" in unmerge_files:
 			candidate_catpkgs.extend(getlist("system"))
@@ -1686,7 +1710,11 @@
 	mydepgraph=depgraph(myaction,myopts)
 	favorites=[]
 	syslist=getlist("system")
-	if myaction in ["system","world"]:
+	if myaction in ["system","world","universe"]:
+		if "universe"==myaction:
+			print "Creating universe",
+			os.system ( '/usr/lib/portage/bin/pkglist | /bin/sed \'s/\-[0-9].*$//\' > /var/cache/edb/universe' )
+			print "...done!"
 		print "Calculating",myaction,"dependencies  ",
 		if not mydepgraph.xcreate(myaction):
 			sys.exit(1)

[-- Attachment #3: Type: text/plain, Size: 37 bytes --]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] portage suggestion

[Mike Frysinger]

`emerge world --update --deep` updates dependencies of packages in the world 
file ...
-mike

On Sunday 15 December 2002 13:23, Jean-Francois Patenaude wrote:
> Related to this comment in the emerge manpage:
>
> --update (-u)
> 	Updates packages to the most recent version available.	Note that
> 	--update does not have	full functionality  yet.   It  will  not
> 	automatically update dependencies of packages in the world file,
> 	unless they too are in the world file.
>
> I created a kind of "emerge --update universe" that you can find
> in the attached patch.  Comments are welcome !
>
> The patch applies over portage 2.0.45-r5
> md5sum of the original emerge: 7eb429e274ff9713270b1a7b3649c22e
>
> Jf.

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Portage suggestion

[Timo Lindemann]

Hi all,

Everytime I install a Gentoo on a system, I curse and scream about one of 
the major flaws in portage.

Whenever I want just one program emerged, say, on a laptop using xfce4 on 
xfree, USE="-kde -esd -arts
  -alsa -oss":
I want to emerge anjuta, portage wants gnomelibs, which in turn want esd. 
It totally ignores my
useflags, the fact that this notebook does not HAVE sound hardware. OK, 
that would be too much for
portage to know, but the USE is ignored anyway. I just want to run anjuta 
with xfce4.
Okay, I think. Lets emerge all that shit, and get over with.
Next thing, I want licq. I pretend. Guess what appears on the list? artsd! 
I cant stand it, really.
Gentoo would be such a nice distro, but it is ALL BLOATED. The fact that 
it is the best distro out
there does make up to that, but it just would be NICER it didn't have to. 
So I suggest: Let there be
a mode for Portage where all CRITICAL dependencies are shown, what the 
program I want NEEDS to run.
I dont want to have an entire OS installed if I just want one program. 
artsd is not a dep from licq,
but somehow entagled in that kde thing, which I dont WANT to have. So, a 
distinction needs to be
made between USEFUL deps, or standard deps, and CRITICAL deps, or needed 
deps.

What do you think?

Regards,

-- 
Timo Lindemann
Empty coke in the desert.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[James Harlow]

On Fri, Feb 13, 2004 at 01:24:21PM +0100, Timo Lindemann wrote:
> artsd is not a dep from licq,
> but somehow entagled in that kde thing, which I dont WANT to have. So, a 
> distinction needs to be
> made between USEFUL deps, or standard deps, and CRITICAL deps, or needed 
> deps.

I'll comment on this specific case: I don't believe it's possible to
compile kdelibs without arts. So the problem is in the software (if it
is a problem at all) rather than in portage's handling of the software.

> What do you think?

I suggest verifying that you can manually compile licq without kde, and
then posting a bug on bugzilla. Repeat as required until all the
packages you use are useflag-enabled.

-- 
When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him. - Jonathan Swift

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[neuron]

> a mode for Portage where all CRITICAL dependencies are shown, what the

that's actually not a bad idea at all.. I could see that really working for a server.  I suppose setting up useflags on a box like that'd be real important though.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[neuron]

oh yeah, and if you set -qt and -kde licq will compile without artsd probably ;)

check out emerge -pv :)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 13 February 2004 13:24, Timo Lindemann wrote:
> Hi all,
>
> Everytime I install a Gentoo on a system, I curse and scream about one
> of the major flaws in portage.
>
> Whenever I want just one program emerged, say, on a laptop using xfce4
> on xfree, USE="-kde -esd -arts
>   -alsa -oss":
> I want to emerge anjuta, portage wants gnomelibs, which in turn want
> esd. It totally ignores my
> useflags, the fact that this notebook does not HAVE sound hardware.
> OK, that would be too much for
> portage to know, but the USE is ignored anyway. I just want to run
> anjuta with xfce4.
> Okay, I think. Lets emerge all that shit, and get over with.
> Next thing, I want licq. I pretend. Guess what appears on the list?
> artsd! I cant stand it, really.
> Gentoo would be such a nice distro, but it is ALL BLOATED. The fact
> that it is the best distro out
> there does make up to that, but it just would be NICER it didn't have
> to. So I suggest: Let there be
> a mode for Portage where all CRITICAL dependencies are shown, what the
> program I want NEEDS to run.
> I dont want to have an entire OS installed if I just want one program.
> artsd is not a dep from licq,
> but somehow entagled in that kde thing, which I dont WANT to have. So,
> a distinction needs to be
> made between USEFUL deps, or standard deps, and CRITICAL deps, or
> needed deps.

Basically all those deps should be optional if they are not critical. As 
such it is more an ebuild issue than a portage issue. Please file bugs 
for apps that by default have optional deps but don't have a useflag.

Paul

ps. In this case libgnome is actually able to build with only optional 
audio support. This is not enabled in the ebuild and is not clear from 
the (broken) configure script (which does not allow to disable support 
manually)

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFALMjDbKx5DBjWFdsRAoQFAJwMWs9WNVbrLzICRTAarnZoQyMSpACfZmRj
nd2S0rixHp5c632xz2zVK9o=
=O26d
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[Ciaran McCreesh]

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

On Fri, 13 Feb 2004 13:24:21 +0100 Timo Lindemann
<lindem@castor.Uni-Trier.DE> wrote:
| to. So I suggest: Let there be
| a mode for Portage where all CRITICAL dependencies are shown, what the
| program I want NEEDS to run.
| I dont want to have an entire OS installed if I just want one program.
| artsd is not a dep from licq,
| but somehow entagled in that kde thing, which I dont WANT to have. So,
| a distinction needs to be
| made between USEFUL deps, or standard deps, and CRITICAL deps, or
| needed deps.

USE="-* nls readline" comes pretty close...

-- 
Ciaran McCreesh
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Portage suggestion

[Patrick Kursawe]

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

On Fri, Feb 13, 2004 at 01:24:21PM +0100, Timo Lindemann wrote:

> Everytime I install a Gentoo on a system, I curse and scream about one of 
> the major flaws in portage.

Quite a promising start...

[ ... gnome-libs requiring esound ... ]

> Okay, I think. Lets emerge all that shit, and get over with.
> Next thing, I want licq. I pretend. Guess what appears on the list? artsd! 
> I cant stand it, really.

I can't reproduce it. 
USE="-arts -kde" emerge -epv licq | grep arts
gives nothing. Could you please try to use emerge -epv ... to check what
pulls in artsd?

> Gentoo would be such a nice distro, but it is ALL BLOATED. 

Screaming isn't very helpful here.

> Let there be
> a mode for Portage where all CRITICAL dependencies are shown, what the 
> program I want NEEDS to run.

That is what the USE flags and the DEPEND/RDEPEND entries in the ebuilds
were invented for.

> I dont want to have an entire OS installed if I just want one program. 
> artsd is not a dep from licq,
> but somehow entagled in that kde thing, which I dont WANT to have. So, a 
> distinction needs to be
> made between USEFUL deps, or standard deps, and CRITICAL deps, or needed 
> deps.
> 
> What do you think?

I think that the system is already there. The problem is that there's no
standardized way how a program can tell what it needs, so this is up to the
developer who writes the ebuild. Developers (as far as I know) are humans.
Humans make mistakes. That's why there sometimes are DEPENDs which are not
really needed. That's why there sometimes are no DEPENDs which would
actually be needed.

Perhaps this is the point where you should think about this, stop
complaining and start improving gentoo by giving useful bug reports
(http://bugs.gentoo.org) for those packages that have wrong dependencies or
that do not respect USE flags they should be aware of.

Just an idea,

Patrick

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

Re: [gentoo-dev] Portage suggestion

[Spider]

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

begin  quote
On Fri, 13 Feb 2004 12:44:21 +0000
James Harlow <james@is.never.wrong.nu> wrote:



> 
> > What do you think?
> 
> I suggest verifying that you can manually compile licq without kde,
> and then posting a bug on bugzilla. Repeat as required until all the 
> packages you use are useflag-enabled.


I keep seing threads like this cropping up at a regular basis, both here
and on bugzilla.  However, the small issue most people who file those
bugs overlook is reliability.

Here's the point,  we can easly remove the dependency on esd, and if the
code works, okay.  However, then you have an untracked dependency when
esd -is- installed but set as USE="-esd" , as it will be needed, but not
listed as such.

-that-  is unreliable behaviour, and in many cases we chose to rather
make it a hard dependency and force it down peoples throats, than to
expend time and work on issues where things -work- but we perhaps not
locally optimal.

So, Feel free to file any bugs you want about this, tcp-wrappers and
other such "bloated" issues. However:  If you do not wrap for the
reverse case, your changes will be ignored.


//Spider

-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

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

Re: [gentoo-dev] Portage suggestion

[Bartosch Pixa]

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

On Fri, 2004-02-13 at 13:24, Timo Lindemann wrote:

> ...
> So, a distinction needs to be made between USEFUL deps, or standard deps,
> and CRITICAL deps, or needed 
> deps.

this distinction is there, USEFLAGS only control optional deps, what's
not optional gets pulled in if you like it or not. in your case it's
anjuta which is a gnome app, so "-gnome" won't help you at all.

regards
-- 
Bartosch Pixa
Gentoo Linux Developer                    http://www.gentoo.org

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

Re: [gentoo-dev] Portage suggestion

[James Harlow]

On Fri, Feb 13, 2004 at 01:54:53PM +0100, Spider wrote:
> > I suggest verifying that you can manually compile licq without kde,
> > and then posting a bug on bugzilla. Repeat as required until all the 
> > packages you use are useflag-enabled.
> 
> I keep seing threads like this cropping up at a regular basis, both here
> and on bugzilla.  However, the small issue most people who file those
> bugs overlook is reliability.
> 
> Here's the point,  we can easly remove the dependency on esd, and if the
> code works, okay.  However, then you have an untracked dependency when
> esd -is- installed but set as USE="-esd" , as it will be needed, but not
> listed as such.

Sure. I'm implicitly assuming that the --without-esd ./configure switch
does the right thing, which obviously needs to be tested. But it's a
pretty simple test.

That's what you were referring to, right?

-- 
When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him. - Jonathan Swift

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 13 February 2004 13:54, Spider wrote:
> begin  quote
> On Fri, 13 Feb 2004 12:44:21 +0000
>
> James Harlow <james@is.never.wrong.nu> wrote:
> > > What do you think?
> >
> > I suggest verifying that you can manually compile licq without kde,
> > and then posting a bug on bugzilla. Repeat as required until all the
> > packages you use are useflag-enabled.
>
> I keep seing threads like this cropping up at a regular basis, both
> here and on bugzilla.  However, the small issue most people who file
> those bugs overlook is reliability.
>
> Here's the point,  we can easly remove the dependency on esd, and if
> the code works, okay.  However, then you have an untracked dependency
> when esd -is- installed but set as USE="-esd" , as it will be needed,
> but not listed as such.
>
> -that-  is unreliable behaviour, and in many cases we chose to rather
> make it a hard dependency and force it down peoples throats, than to
> expend time and work on issues where things -work- but we perhaps not
> locally optimal.
>
> So, Feel free to file any bugs you want about this, tcp-wrappers and
> other such "bloated" issues. However:  If you do not wrap for the
> reverse case, your changes will be ignored.

I have sent a message to portage-dev to this respect suggesting dynamic 
runtime deps. Basically saying, if this package is available at 
compiletime it will be needed at runtime. This would probably be an 
option for portageng, but it would allow these things to be tracked.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFALMtmbKx5DBjWFdsRAn8gAJ9RI1b1jsa7/yMOrMk+ad3HJgjp7ACeKxnn
Pzw5fl3GZwup9VUf4YJILwA=
=Cwrb
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[Patrick Kursawe]

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

On Fri, Feb 13, 2004 at 01:03:32PM +0000, James Harlow wrote:
> Sure. I'm implicitly assuming that the --without-esd ./configure switch
> does the right thing, which obviously needs to be tested. But it's a
> pretty simple test.

For gnome-libs 1.4.2:

./configure --help | grep esd
  --with-esd-prefix=PFX   Prefix where ESD is installed (optional)
  --with-esd-exec-prefix=PFX Exec prefix where ESD is installed (optional)
  --disable-esdtest       Do not try to compile and run a test ESD program

Of which switch are you speaking?

Wondering,

Patrick	

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

Re: [gentoo-dev] Portage suggestion

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 13 February 2004 14:10, Patrick Kursawe wrote:
> On Fri, Feb 13, 2004 at 01:03:32PM +0000, James Harlow wrote:
> > Sure. I'm implicitly assuming that the --without-esd ./configure
> > switch does the right thing, which obviously needs to be tested. But
> > it's a pretty simple test.
>
> For gnome-libs 1.4.2:
>
> ./configure --help | grep esd
>   --with-esd-prefix=PFX   Prefix where ESD is installed (optional)
>   --with-esd-exec-prefix=PFX Exec prefix where ESD is installed
> (optional) --disable-esdtest       Do not try to compile and run a
> test ESD program
>
> Of which switch are you speaking?

Anjuta uses libgnome (not gnome-libs) which does not respond to a 
- --without-esound (or similar) argument (I checked it in the configure 
script). Basically this could be fixed but it would be a lot of work. 
Dynamic dependencies could be a solution.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFALNFLbKx5DBjWFdsRAogDAKCWCcTeG0/+Llv/DIBBxQKuktO7ygCgkkht
vNkmalbANN59g7fd1j24oq0=
=b315
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[James Harlow]

On Fri, Feb 13, 2004 at 02:10:02PM +0100, Patrick Kursawe wrote:
> On Fri, Feb 13, 2004 at 01:03:32PM +0000, James Harlow wrote:
> > Sure. I'm implicitly assuming that the --without-esd ./configure switch
> > does the right thing, which obviously needs to be tested. But it's a
> > pretty simple test.
> 
> For gnome-libs 1.4.2:
> Of which switch are you speaking?

I was speaking generally, and muddied my point by talking about a
specific package. Sorry.

-- 
When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him. - Jonathan Swift

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[Spider]

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

begin  quote
On Fri, 13 Feb 2004 13:03:32 +0000
James Harlow <james@is.never.wrong.nu> wrote:


> > Here's the point,  we can easly remove the dependency on esd, and if
> > the code works, okay.  However, then you have an untracked
> > dependency when esd -is- installed but set as USE="-esd" , as it
> > will be needed, but not listed as such.


 
> Sure. I'm implicitly assuming that the --without-esd ./configure
> switch does the right thing, which obviously needs to be tested. But
> it's a pretty simple test.
> 
> That's what you were referring to, right?

No, if that isn't used its a simple thing to add a USE flag.  The issue
is with things that go...
"do I have alsa?  no...  not building alsa interface"
"do I have esound? no .. not building esound interface"   


without a choice to -disable (or enable) such things, when you can state
USE="-*" and then still get everything included, no dependencies tracked
and a hosed system when you finally try to live without alsa+esound.

too many builds use auto* functions like that, and no. "dynamic
dependencies" isn't a solution here either.   Metal hacking configure.*
is however one.


//Spider

-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

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

Re: [gentoo-dev] Portage suggestion

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 13 February 2004 14:46, Spider wrote:
>
> too many builds use auto* functions like that, and no. "dynamic
> dependencies" isn't a solution here either.   Metal hacking
> configure.* is however one.

Of course fixing the configure script is the only final solution. In some 
cases that can be cumbersome however. I think a dynamic dependency can 
relieve this somewhat, allthough it will allways be worse than useflags 
in a case where useflags would be appropriate.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFALNnEbKx5DBjWFdsRAnJyAKC5PwT6/q/wiDirLflQsqgCcEaKlACeP6pm
ANzViIvy/oLs5FAaWeYWYA4=
=Cx7a
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[Kumba]

James Harlow wrote:

> I'll comment on this specific case: I don't believe it's possible to
> compile kdelibs without arts. So the problem is in the software (if it
> is a problem at all) rather than in portage's handling of the software.

Actually, with KDE 3.2, it is possible.  I may not be an X person, but 
last time I tried KDE 3.2 when it was in beta, the configure scripts 
supported a --without-arts line, and I partially hacked the KDE eclasses 
to pass this.  I managed to get kdelibs and kdebase built w/o arts, and 
it ran fine.  kdegames was another matter -- kasteroids still doesn't 
honor the --without-arts configure flag (probably just needs some 
tweaking to its Makefile to fix this).

I recommend the KDE team look into the --without-arts parameter for KDE 
3.2, and consider implementing it for the -arts USE flag.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[Mike Frysinger]

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

On Friday 13 February 2004 07:24 am, Timo Lindemann wrote:
> Everytime I install a Gentoo on a system, I curse and scream about one of
> the major flaws in portage.
> OK,
> that would be too much for
> portage to know, but the USE is ignored anyway.

use /etc/portage/package.mask and dont complain when you try to emerge 
something that *needs* that package to build
-mike

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

Re: [gentoo-dev] Portage suggestion

[foser]

On Fri, 2004-02-13 at 13:24, Timo Lindemann wrote:
> Hi all,
> 
> Everytime I install a Gentoo on a system, I curse and scream about one of 
> the major flaws in portage.
> 
> Whenever I want just one program emerged, say, on a laptop using xfce4 on 
> xfree, USE="-kde -esd -arts
>   -alsa -oss":
> I want to emerge anjuta, portage wants gnomelibs, which in turn want esd. 
> It totally ignores my
> useflags, the fact that this notebook does not HAVE sound hardware. OK, 
> that would be too much for
> portage to know, but the USE is ignored anyway. I just want to run anjuta 
> with xfce4.

USE flags are about _optional_ deps, not about needed deps. So far not a
flaw in portage, but a flaw in your reasoning.

> Okay, I think. Lets emerge all that shit, and get over with.
> Next thing, I want licq. I pretend. Guess what appears on the list? artsd! 
> I cant stand it, really.
> Gentoo would be such a nice distro, but it is ALL BLOATED. The fact that 
> it is the best distro out
> there does make up to that, but it just would be NICER it didn't have to. 

Well, it's probably the least bloated of distros as well. You want less
bloat? Hands on source compilation might save you a few deps, but i
don't think it makes much of a difference.

> So I suggest: Let there be
> a mode for Portage where all CRITICAL dependencies are shown, what the 
> program I want NEEDS to run.
> I dont want to have an entire OS installed if I just want one program. 
> artsd is not a dep from licq,
> but somehow entagled in that kde thing, which I dont WANT to have. So, a 
> distinction needs to be
> made between USEFUL deps, or standard deps, and CRITICAL deps, or needed 
> deps.
> 
> What do you think?

I think 'show me the code'. No i didn't think that, it's just not a very
good idea. A better thing to have would be portage support for USE
flagged deps in ebuilds, but afaic there's bugs open about that & it's
quite a tricky issue.

As far as bloatness goes, if you can prove something is bloated you can
open a bug, because it's a mistake. Every dep not explicitly needed
should not be in the dep listing (or be USE flagged), given that it
_can_ be hard switched.

Now to get back to the gnome-libs case, iirc esound theoreticly can be
switched, but even then the major amount of use cases would need it to
be compiled with the switch. So to avoid a large amount of bugreports we
haven't made it optional, this will likely not be fixed until previous
mentioned portage feature exists. Until then you can always use your
texteditor (power to the user) and remove the offending dep yourself.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[Thomas de Grenier de Latour]

On Sat, 14 Feb 2004 19:28:25 +0100
foser <foser@foser.dyn.warande.net> wrote:

> A better thing to have would be portage support for
> USE flagged deps in ebuilds, but afaic there's bugs open about that &
> it's quite a tricky issue.

What kind of behavior would you expect from such a dep? Assume you have
gnome-libs installed without esd support and your package depends on
gnome-libs with esd. Should emerge force reinstallation of gnome-libs,
or just fail? I'm just curious. 

Thanks, 

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage suggestion

[Mike Frysinger]

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

On Saturday 14 February 2004 01:54 pm, Thomas de Grenier de Latour wrote:
> What kind of behavior would you expect from such a dep? Assume you have
> gnome-libs installed without esd support and your package depends on
> gnome-libs with esd. Should emerge force reinstallation of gnome-libs,
> or just fail? I'm just curious.

re-emerge it and/or spit an error explaining the problem
there's already bugs open about this because we need this kind of dependency 
tracking
-mike

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

Re: [gentoo-dev] Portage suggestion

[Spider]

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

begin  quote
On Sat, 14 Feb 2004 19:54:46 +0100
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:

> On Sat, 14 Feb 2004 19:28:25 +0100
> foser <foser@foser.dyn.warande.net> wrote:


> What kind of behavior would you expect from such a dep? Assume you
> have gnome-libs installed without esd support and your package depends
> on gnome-libs with esd. Should emerge force reinstallation of
> gnome-libs, or just fail? I'm just curious. 

DEPEND="gnome-base/gnome-libs[+esd]"    or somekind, if that isn't
supported, force a re-merge of gnome-libs with USE="+esd" no matter what
said person had before.


//Spider


-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

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