Search:  
Gentoo Wiki

GLEP-0021

This is a place to consolidate information that is potentially useful for an implementation of GLEP-21. Hopefully this will make it easier for someone to implement it.

Contents

Online References

Mailing List References

Forums References

Demonstrations of current meta-package problems

Code References

My poor Portage deconstruction by: g2boojum

http://sources.gentoo.org/viewcvs.py/portage/

Portage/bin

emerge

emerge trunk 2.1.2 2.1.1

place for the interface (and possibly a whole lot more.

It looks, at a glance, like world and system are 'actions' (ie emerge clean has the "clean" action, but emerge --clean has the "clean" option. Therefore emerge world would be interpreted with "world" as an action, not as a package to emerge and not as an option). (see also ~line 180-210)

Perhaps sets can tie into some of the existing world functionality, as 'world' is based on the 'world' file. 'system' on the other hand, is a generated list, or at least it is treated differently throughout emerge.

World is implemented in emerge, not in portage.py, so sets will probably need to be implemented in emerge as well

Perhaps one implementation would be to create a new mytype "set".

Code: example of mytpe ~line 952
 
945 : 	except ValueError, e:
946 : 		pkgs = e.args[0]
947 : 		portage.writemsg("\n\n!!! An atom in the dependencies " + \
948 : 			"is not fully-qualified. Multiple matches:\n\n", noiselevel=-1)
949 : 		for cpv in pkgs:
950 : 	 		portage.writemsg(" %s\n" % cpv, noiselevel=-1)
951 : 		portage.writemsg("\n", noiselevel=-1)
952 :  		if mytype == "binary":
953 :  			portage.writemsg(
954 : 				"!!! This binary package cannot be installed: '%s'\n" % \
955 :  				mykey, noiselevel=-1)
956 :  		elif mytype == "ebuild":
957 :  			myebuild, mylocation = portdb.findname2(mykey)
958 :  			portage.writemsg("!!! This ebuild cannot be installed: " + \
959 : 				"'%s'\n" % myebuild, noiselevel=-1)
960 :  		portage.writemsg("!!! Please notify the package maintainer " + \
961 :  			"that atoms must be fully-qualified.\n", noiselevel=-1)
962 :  		return 0
963 : 	return 1
  

It looks like the --package-set option will need to be implemented in merging (def merge ~line 2221) at a minimum. Possibly in unmerge and other locations as well.

In regards to unmerging - what will happen when someone unmerges a set? (eg emerge -C <some set here>) I would think that all of the packages in that set would be removed. What about the dependencies of those packages? Leave them alone? That'd probably be the most consistent approach as cleaning/unmerging/-C does not remove dependencies and is probably less work to implement that way. Currently unmerge doesn't allow unmerging system or world (duh) but I think it should be able to unmerge sets (see ~line 2625)

Will action_sync need to be aware of sets at all? How are sets going to be distributed (eg the kde sets)? User sets will be in /etc/portage/sets but what about mirrored sets? Perhaps in a profile, but profiles aren't released as often as packages are (eg kde). We'd need some kind of new mirrored sets file...

action_config (~line 3480) will need to exclude sets as it excludes world and system. If it doesn't exclude it, sets will need some kind of special handling in action_config

If USER_SETS_PATH or equivalent is set in make.conf - that'll need to be export by emerge --info (action_info) see ~line 3605 Also, we'll want to implement sets in a way that emerge --info <packaqe set name> still works on it

action_depclean (~line 3713) may need to be aware of sets to make sure it doesn't botch them.


Code: World and system called "package class" not a set, which may need to be changed to be consistent ~line 4326
 
	if (myaction in ["world", "system"]) and myfiles:
		print "emerge: please specify a package class (\"world\" or \"system\") or individual packages, but not both."
		sys.exit(1)
  

regenworld

regenworld trunk 2.1.2 2.1.1

potential information on package db and on world file

We may need to do something in regenworld to make it put sets in the world file, however it doesn't look necessary upon a brief code inspection.

pemerge.py

pemerge.py trunk 2.1.2 2.1.1

has emerge in the name, looks promising as anothe place for interface

Then again, upon inspection it appears this is just some kind of timer to collect statistics or something. It doesn't look like sets will touch this file.

ebuild.sh

ebuild.sh trunk 2.1.2 2.1.1

ebuild.sh is used in emerging each package, and as "sets" are lists of packages, emerge should figure out the dependencies and ebuild.sh should never see anything about "sets". What would happen if someone called ebuild.sh merge <name of a set> ?

ebuild

ebuild trunk 2.1.2 2.1.1

see comments on ebuild.sh

misc-functions.sh

misc-functions.sh trunk 2.1.2 2.1.1

A bunch of miscelaneous functions that don't go in ebuild.sh (see comments on ebuild.sh) but I don't think this file will have anything to do with a sets implementation.

Portage/pym

pym trunk 2.1.2 2.1.1

The Main Portage Directory

portage.py

portage.py trunk 2.1.2 2.1.1

The core portage file where the backend will go (I think) In searching for world, it looks like the world functionality isn't in portage itself... I'll have to search/trace what happens when emerging.

Code: USER_SETS_PATH ~line67
 
65 : 	import portage_const
66 : 	from portage_const import VDB_PATH, PRIVATE_PATH, CACHE_PATH, DEPCACHE_PATH, \
67 : 	  USER_CONFIG_PATH, MODULES_FILE_PATH, CUSTOM_PROFILE_PATH, USER_SETS_PATH, PORTAGE_BASE_PATH, \
68 : 	  PORTAGE_BIN_PATH, PORTAGE_PYM_PATH, PROFILE_PATH, LOCALE_DATA_PATH, \
69 : 	  EBUILD_SH_BINARY, SANDBOX_BINARY, BASH_BINARY, \
70 : 	  MOVE_BINARY, PRELINK_BINARY, WORLD_FILE, MAKE_CONF_FILE, MAKE_DEFAULTS_FILE, \
71 : 	  DEPRECATED_PROFILE_FILE, USER_VIRTUALS_FILE, EBUILD_SH_ENV_FILE, \
72 : 	  INVALID_ENV_FILE, CUSTOM_MIRRORS_FILE, CONFIG_MEMORY_FILE,\
73 : 	  INCREMENTALS, EAPI, MISC_SH_BINARY
  

portage_dep.py

portage_dep.py trunk 2.1.2 2.1.1

dependency resolution might need to be touched to get sets working (maybe)

Would it be possible to have slotted sets? If so, something might need to go here.

portage_update.py

portage_update.py trunk 2.1.2 2.1.1

The update script might need something to get it to use sets

portage_const.py

portage_const.py trunk 2.1.2 2.1.1

Constants like where world is go here. /etc/portage/sets/ will need to go here

Code: USER_SETS_PATH addition
...
USER_CONFIG_PATH        = "/etc/portage"
MODULES_FILE_PATH       = USER_CONFIG_PATH+"/modules"
CUSTOM_PROFILE_PATH     = USER_CONFIG_PATH+"/profile"
USER_SETS_PATH          = USER_CONFIG_PATH+"/sets"
...
 

Then again, maybe the sets path should be configurable via make.conf - would that have any benefit? If so, USER_SETS_PATH might not go here after all.

output.py

output.py trunk 2.1.2 2.1.1

output stuff like colors, perhaps a new color for sets?

emergehelp.py

emergehelp.py trunk 2.1.2 2.1.1

emerge --help stuff; will need information on sets capability

portage_util.py

portage_util.py trunk 2.1.2 2.1.1

Potentially useful utilities

portage_debug.py

portage_debug.py trunk 2.1.2 2.1.1

Debug stuff'll probably need to be included or something

Portage/man

man trunk 2.1.2 2.1.1

man pages go here, they'll need to be updated

Retrieved from "http://www.gentoo-wiki.info/GLEP-0021"

Last modified: Fri, 05 Sep 2008 06:57:00 +0000 Hits: 2,015