> would indicate easily if any packages in the special list are upgradable > irregardless of whether it is in world, system, whatever.
Ok. Kind of mirroring, then. >From where the "current version" identifier for each package comes, then? Will the packages be just downloaded to that central computer and kept up-to-date there? Is "list" specifier needed as there are many lists anyway? I mean, there is no "--list" before world or system. ---------------------------------------------------- Actually, it seems to me that "emerge" should be divided into smaller packages so that users could do such things by scripting. For example, if there were utilities, which build different types of lists [system, kde-meta, world] and output them in some standard format, optionally including versions. elist --currently_installed >> world.list && elist kde-meta kdevelop >> packages.list. Then utility, which takes list into stdin and outputs, which items are newer in server. Then utility for different kinds of comparations of lists (mix -- mixes two lists into one; onlyinfirst, newerversioninfirst and so on). Then utility, which is able to emerge all packages, which are contained in a specific list. What i mean -- it should be possible to use more shell scripting in portage. Any competent admin would be able to run "elist --currently_installed >> world.list" on all machines, then mix them in one machine and check for updates (and then download all those updates into local cache, for example). This should be discussed more deeply, but i think that if portage is divided into several smaller tools, it would be simpler to develop and more scalable. In such case, what portage is about -- lists and checking them against each other; emerging everything in given list; unmerging everything in given list; checking for dependancies of a given list. It is not a small work to think out exactly *how* it should be divided, but i think that the results would be worth of it. Currently, imho, the portage code is grown complex enough that making it simpler is more important than giving new features to it -- if it becomes simple and robust, many new features will find their way in by themselves without any work on developer side, i think :) So, if portage would be looked as lists and operations with lists (calculating dependencies of package would be operation with list of that package and list of all - portage tree -, then); building tools [shell commands] for creating those lists and tools for operations with those lists and leaving "emerge" tool just a handy interface to command them would be imho great. So, something like: # create list file of all in world $ elist --currently_installed --options=fullname,installedversion >> world.list # is cmd for create list file of all in portage tree too slow or usable enough? # check if list of all (portage tree) contains anything newer (all.list is symbolic name here for portage tree to get interface ordered) $ ecompare world.list all.list --newer --deep >> update.list # there is another computer, which is not connected to internet, but has some needs, too $ ecompare othercomputerworld.list all.list --newer --deep >> update2.list # mix those lists together $ emix update.list update2.list >> allupdates.list # download updates $ efetch allupdates.list --where /var/portageupdates # copy all updates mentioned in update.list to CD image .... # update [build and install] all packages, using /var/portageupdates as source of tar files .... -- tvali >From a programmer's point of view, the user is a peripheral that types when you issue a read request. -P. Williams If you think your management doesn't know what it's doing or that your organisation turns out low-quality software crap that embarrasses you, then leave. -Ed Yourdon We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -Larry Wall [ http://www.softwarequotes.com/ ] - http://www.softwarequotes.com/ShowQuotes.asp?ID=544&Name=Borenstein,_Nathaniel_S. - http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry -- [email protected] mailing list
