Bugzilla Bug 33526

The attached ebuild installs the 4 utilities that the dmidecode suite consists
of.

Created an attachment (id=20763) [edit]
Ebuild for dmidecode 2.3

Created an attachment (id=20839) [edit]
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 an attachment (id=20859) [edit]
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 an attachment (id=21609) [edit]
dmidecode-2.3.ebuild, updated DEPEND-line

Please elaborate on your disk I/O remarks.
DEPEND-line updated.

Created an attachment (id=21610) [edit]
dmidecode-2.3.ebuild, updated DEPEND-line (the right one this time)

Previous one was unchanged, due to a failed SCP.

Created an attachment (id=21611) [edit]
"Disk I/O checked" dmidecode-2.3.ebuild

|| die statements added on Mr_Bones_'s request.

Created an attachment (id=21612) [edit]
More "disk I/O checking" for dmidecode-2.3.ebuild

Mr_Bones_ would prefer a || die behind the sed too.

Created an attachment (id=21613) [edit]
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 an attachment (id=25095) [edit]
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 an attachment (id=27842) [edit]
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 an attachment (id=27913) [edit]
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 an attachment (id=28259) [edit]
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 :)