Hello, I've written a useful script to parse Gentoo's metadata.xml file. Currently there aren't many tools which take advantage of the full file, so this script may be useful to power users, arch testers, or devs. The script is well tested and feature-complete. I think it would be a good fit for inclusion in gentoolkit, as it was designed with that in mind (uses the same color scheme, etc). Please let me know if there is anything I need to change. Also, no biggie if it wouldn't be a good fit for inclusion in the main tree. I wrote it for myself, but I hope others find it useful. Reproducible: Always Steps to Reproduce: 1. Review features here: http://code.google.com/p/genscripts/wiki/emeta 2. Review code here: http://code.google.com/p/genscripts/source/browse/emeta/trunk/emeta 3. layman -f -o http://genscripts.googlecode.com/files/layman.xml -a genscripts 4. emerge emeta Actual Results: $ emeta --test Test * app-test/Test Herd: herd-one herd-two Maintainer: maitainer-one@gentoo.org Mr. One lead maintainer maintainer-two@gentoo.org Mr. Two secondary maintainer Upstream: Maintainer: Foo Bar foo@bar.bar (inactive) Foo Gentoo foo@gentoo.org (active) Changelog: http://foo.bar/changelog.txt Docs: http://foo.bar/doc/index.html (en) http://foo.bar/doc/index.de.html (de) Bugs to: https://bugs.foo.bar Remote ID: freshmeat: foobar sourceforge: foobar Description: None specified Useflags: acpi Enables HAL to attempt to read from /proc/acpi/event, if unavailable, HAL will read events from sys-power/acpid. If you need multiple acpi readers, ensure acpid is in your default runlevel along with HAL. This will also enable HAL to read Toshia and IBM acpi events which do not get sent via /proc/acpi/event crypt Allows HAL to mount volumes that are encrypted using LUKS. sys- fs/cryptsetup-luks which has recently been renamed to sys- fs/cryptsetup allows you to create such encrypted volumes. HAL will be able to handle volumes that are removable or fixed. dell Builds an installs the Dell addon, which reads data from the Dell SM BIOS via sys-libs/libsmbios. It will read your service tag information and your hardware backlight data as well as allow you to modify the backlight settings on a Dell laptop. disk-partition Allows HAL to use libparted from sys-apps/parted to read raw partition data from your disks and process that data. Future versions of HAL (possibly 0.5.11 and higher) will allow you to create, modify, delete and format partitions from a GUI interface agnostic of your desktop environment. doc Generates documentation that describes HALs fdi format. pcmcia Allows HAL to process PCMCIA/CardBus slot data which includes inserts and removals and act on these events. selinux (for >=sys-apps/hal-0.5.11) Installs SELinux policies and links HAL to the SELinux libraries.
Thanks Douglas! Assigned to tools-portage team.
Added filename extension for script in trunk, so latest source can now be viewed here: http://code.google.com/p/genscripts/source/browse/emeta/trunk/emeta.py
I like it! I think it should be invoked as "equery meta". Agree, disagree?
(In reply to comment #3) > I like it! I think it should be invoked as "equery meta". Agree, disagree? > I wouldn't be averse to that. emeta already uses the same -q|quiet and -C|nocolor options as equery and also shares it's color scheme (it uses the same portage module for colorization as equery does), so it would be trivial to change it from a script to a module. If it were to be an equery module, it would probably be good to reduce the number of options. One idea would be to combine --herd, --maint and --upstream into one --maint option. --xml probably isn't _that_ useful outside of testing, either. After passing through equery's --quite and --nocolor, that would leave a rather manageable set of options. It might look like: $ equery meta Usage: <local-opts> pkgspec Parse an ebuild's metadata file for useful information Options: -c, --current parse metadata.xml in the current directory -d, --desc show an extended package description -m, --maint show the herd and maintainer(s) for the package -u, --useflags show per-package USE flag descriptions
I'm not a lawyer and haven't looked over the fine details, but I have a concern that emeta is licensed as GPLv3 and gentoolkit is GPLv2. Before we add it to gentoolkit, we need to makes that any implications due to that licensing are worked out (if any).
(In reply to comment #5) > I'm not a lawyer and haven't looked over the fine details, but I have a concern > that emeta is licensed as GPLv3 and gentoolkit is GPLv2. Before we add it to > gentoolkit, we need to makes that any implications due to that licensing are > worked out (if any). > Good point. I think GPLv3 is the better license for a number of reasons. For small programs, there's almost no reason at all not to use the most recent version. However, I did check, and you _can't_ include GPLv3 code in a GPLv2 only program. http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility So two possibilities. One, I can re-license emeta as 'GPLv2 or later' or two, gentoolkit could relicense to GPLv3. Let me know.
emeta is now 'equery meta' in the latest gentoolkit. The version of gentoolkit I've been working on also has massive amounts of cleanup in equery, and some good stuff for users of the gentoolkit API in the new helpers2.py. I'll have a more formal introduction to the work I've done at a later point... for now, you can help me test and let me know your thoughts: 1) layman -f -o http://genscripts.googlecode.com/files/layman.xml -a genscripts 2) layman -s genscripts 3) emerge gentoolkit 4) equery meta -h Thanks for your interest and input, -Doug
(In reply to comment #7) > 1) layman -f -o http://genscripts.googlecode.com/files/layman.xml -a genscripts I just added the overlay to layman-global.txt
emeta is in gentoolkit-0.3 as equery meta
