> tgz support: A tgzfile must be a Slackware pkg. Emerde will resolve the > tgz's dependences and will install it. If '.tgz' has been reserved for slackware, that's a bit of a problem. The following suggestion requires some changes in portage, but they are on the way. I'd prefer if it detected the slackware info within the file. Portage should be able to handle any tarball given, regardless of it's metadata format. The reason I say the reservation is a problem stems from wanting xpaks on tgz files instead of restricting ourselves to tbz2 which is computationally intensive. > pfile: Emerde will apply the specified action to all the > packages listed in the pfile I don't know what this means. > invulnerable: Updates all the packages which have suid binaries. Why? > slack-etc-update: Slackware configuration file updates handler. Ok. > maketgz: Emerde will build Slackware's tgz packages for all > ebuilds processed. Converting to an outside format, while good to be able to do, is better served in an outside application. You had mentioned in another message por2pkg or something like that. These would be in the package to which I am refering. > quicksearch: The cp_all function in Emerde is rewritten to use > /var/cadb, there's a significant improvement in all > the functions that use cp_all (--search, sync, > update cache etc...) What is cadb? 'esearch' and it's friends compile the data into a db it uses to query from. The problem with portage's search is a locality problem. Seeks on disks are a major penalty. What benefit are you providing here? > skipit: Emerde allows you to skip to the next merge with the > SIGINT signal or by pressing CTRL+c. This probably isn't a good idea. It's liable to break 'automatic' configurations that the ebuild expects to be satisfied in a particular way. Do you use this often? > Compilation resume: Emerde resumes an interrupted or aborted > compilation without rebuild the pkg and > restart the compilation. I commented on this elsewhere. > LAN-sync: The syncing of the portage can be done using another > machine that had already done it. See ACTION:sync in > the emerge(1) man page. You can share your portage tree via NFS and 'emerge metadata'. What does this gain you beyond that? > --searchcontents: Emerde matches the search string against the > contents field. The pkg's contents field > contains a list of files and directories > installed. This option is useful to know to > what pkg a file or a directory belong. External apps do this for us now. See 'etcat -b' and 'qpkg -f'. > --showcontents: This option is the same as the --search one except > that it shows all the contents file of the searched > packages. What's the use/benefit of this? > --searchinstalled: It filter only installed pkg in the search result. The idea is good. The number of flags that could be used here might be a problem though. Perhaps it's time we support '=' in arguments: --search=description,installed,available,masked or something to that effect might be more effective. > buildworld: Rebuilds or updates the "world" file (/var/cache/edb/world) /usr/lib/portage/bin/regenworld > por2pkg: converts entries in the portage's db to Slack's db entries. > pkg2por: converts entries in the Slack's db to portage's db entries. Commented earlier. > pordbcheck: Checks if the programs listed in the portage's db are > really installed. I know that qpkg can do this. I'm not overly fond of qpkg as it's in bash and generally annoying to fix. > initd-cfg: /etc/init.d editor. Explanation would be nice... What exactly is it editing? > If I can jump in the coding with you, I can live in peace > with emerde because all the changes will be already built > in and in the near future emerde won't be needed anymore. > The goal is to make the portage distro independent. I've got no problem with more help, but as with everyone else, we need to look over what you've done, and how you've done it before bringing you on board. I'll be looking over everything at some point. Just have to find the time. --NJ