The attached ebuild installs the 4 utilities that the dmidecode suite consists of.
Created attachment 20763 [details] Ebuild for dmidecode 2.3
Created attachment 20839 [details] DMIdecode ebuild Revamped the ebuild file, made the SRC_URI more portable, added documentation in pkg_postinst, added missing sed DEPEND.
The suggested category for this package is sys-apps. Besides a description change, the KEYWORDS have been updated, as upstream reports the package working on more archs.
Created attachment 20859 [details] Ebuild with IA64 capabilities. In this version, -sparc has been added after comments in #gentoo-sparc. Supporting it is possible by setting specific ARCHFLAGS, but no sparc has DMI, it wouldn't be useful. The README on their website is outdated, after viewing the one included with the sources, the handling of IA64 has been updated and should work. I haven't yet found testers for it, though.
Why does it depend on wget? That seems odd. Also, more checking could be done on the disk i/o. The sed especially needs to be checked. Also, since sed -i is used, it needs to depend on >=sys-apps/sed-4 since that was the first version that supported that feature.
Created attachment 21609 [details] dmidecode-2.3.ebuild, updated DEPEND-line Please elaborate on your disk I/O remarks. DEPEND-line updated.
Created attachment 21610 [details] dmidecode-2.3.ebuild, updated DEPEND-line (the right one this time) Previous one was unchanged, due to a failed SCP.
Created attachment 21611 [details] "Disk I/O checked" dmidecode-2.3.ebuild || die statements added on Mr_Bones_'s request.
Created attachment 21612 [details] More "disk I/O checking" for dmidecode-2.3.ebuild Mr_Bones_ would prefer a || die behind the sed too.
Created attachment 21613 [details] dmidecode-2.3.ebuild Newest version, there's a remark about not using mirror://, but savannah is not yet in /usr/portage/profiles/thirdpartymirrors
Created attachment 25095 [details] dmidecode-2.3.ebuild Download URI has changed (restructured download directories on Savannah).
i've tested this (well in fact i did not dig thru bugzilla and wrote my own trival ebuild) on ia32 (various machines), opteron with i686-code (one machine) and it seems to work fine. side-note: "sys-apps/lm-sensors" seems to ship it's own version of at least dmidecode; should a blocking-dependency be added?
Created attachment 27842 [details] dmidecode-2.4.ebuild new version (this one contains man-pages for all installed tools). compared to the 2.3-attachement this is missing: - the "ia64" stuff (I have no access to that arch) - DEPEND is empty (I seem to remember that "glibc" may be omitted, is that correct?; I did not see sed needed, so "sed-4" is also gone).
You use sed in your ebuild, this means you're going to have to depend on it. (Version 4 because you use -i). I don't have access to IA64 either, please read the documentation that comes with it, that's how I did 2.3 If not much is changed, please don't try to reinvent the wheel and work from what's there.
sed: mostly correct (I do not use "-i"). about re-invention: see comment #12, that's the version I'm using for some time, tested on various machines -- so I posted that "known good" version -- feel free to merge with yours.
Comment 12 does not contain any ebuilds. If you do not use -i, you still have to depend on sed, because you use it in your ebuild. Your current ebuild will break if you use it on a system without sed, because portage won't merge it first. You don't tell portage that you need it. Without -e, just the "it has to be version 4 or up" requirement is gone.
Created attachment 27913 [details] dmidecode-2.4.ebuild A first attempt at merging Thomas's way of working into a correct ebuild. Please test. (Note: Done on a windows machine, please do tell me if linebreaks are awry)
great! I'd personally delete the pkg_postinst() -- it's pretty obvious that these pgms have been installed (in general ewarn() is not the correct way to inform users -- it should be einfo() ). just my curiosity: any comments on the "virtual/glibc" depend anybody?
The virtual/glibc DEPEND can go, I see no harm in removing it. It was in the original ebuild I looked at, so I kept it. Anyway... those ewarns are there for programs that may not work because they are vendor-specific, and they should have orange bullets instead of green ones. Most of the rest of it is einfo. Just look at it in it's proper format and you'll see why immediately. I'll remove that tomorrow, anything else on your wishlist? (besides ewarn, I like it this way).
ok a last (cosmetic) thing: in src_unpack() the "local ARCHFLAGS"-declaration should go to the top of the function -- it's common to declare vars at the top of a function (eases maintainability and avoid "basic-like confusions" ;)
Created attachment 28259 [details] dmidecode-2.4.ebuild You need to focus on functionality more then cosmetics, because I missed a trailing g in a sed. Which is way more important then a whether local ARCHFLAGS is on top or before the statement that uses it. Anyway, I expect you to obsolete your attachment now that I have addressed all issues you raised. (I also updated the copyright year)
well -- take my ebuild as obsoleted. for the cosmetic side: i didn't download or test your ebuild; as i said: i posted my "know-good"-version and expected you to do something similar. btw: code-maintainablility _is_ important, even if it seems pedantic sometimes.
I was just about to write an ebuild myself, when I found this. Tested the latest on x86, works till now.
The ebuild (id=28259) merged fine Please add this package to portage, It's needed by http://gentoo-stats.org/ to determine the _real_ amount of CPU's installed.
please put it into portage ASAP! ;-)
This appears to work for me, except the ebuild appearing to have DOS line breaks. I suggest moving it into the tree now.
touched up a bit more and added to portage, thanks everyone :)
