This ebuild is for the 3ware 3DM2 management utility for 3ware raid controllers. The ebuild is similar to sys-block/tw_cli because the tarballs are only available from the 3ware website after clicking through the EULA.
Created attachment 64423 [details] ebuild and files for the 3ware 3dm2 management utility Tested on x86 and should work on amd64 too, but unable to test.
No tarballs, please. Attach plaintext ebuild. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3#doc_chap2
Created attachment 64426 [details] 3dm2 ebuild The ebuild for 3ware 3DM2 management utility
Created attachment 64427 [details] default 3dm2 config file
Created attachment 64429 [details] init script for the 3dm2 daemon
1/ Header is invalid. 2/ Keywords do not follow policy. 3/ Please, remove redundant comments mess, leave only the needed ones. 4/ Empty DEPEND is redundant. 5/ Indenting is incorrect, use tabs. 6/ Don't untar in the ebuild and definitely not in src_install(), use src_unpack(). Make the user download the needed files before actually doing anything else in the ebuild. 7/ There are probably more, but the ebuild is pretty unreadable now. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3 Reopen after you have fixed the above problems. Thanks.
There has also been some inventive creation of new functions in the ebuild. Creative, but also violates the QC process. Please check out jakub's link, and hope to see a new QC passing ebuild soon
Created attachment 67003 [details] 3dm2-9.2-r1 ebuild
Hi, I attempted to address the items you mentioned in your review of the 3dm2 ebuild. Please review and let me know if you see any additional problems. FYI, the original ebuild used sys-block/tw_cli as an example. It seems to suffer many (if not all) of the problems you pointed out for the 3dm2 ebuild. I'm not complaining, but just trying to point out that evidently there are ebuilds already in portage that don't meet the standards being used to review new ebuilds. Thanks, jthomps
(In reply to comment #9) > Hi, I attempted to address the items you mentioned in your review of the 3dm2 > ebuild. Please review and let me know if you see any additional problems. Thanks for attaching a new ebuild. 1/ There are still problems w/ indenting in DOWNLOAD_URL and SRC_URI. 2/ einfo " " is not needed, just plain einfo will do the job. ;) 3/ You should add || die "uncompressing xxx failed" or to those tar xzf lines in src_unpack() ; why upstream tarball contains another gzip-ed things goes beyond me :) Please, fix those problems as well and attach a new ebuild. > FYI, the original ebuild used sys-block/tw_cli as an example. It seems to suffer > many (if not all) of the problems you pointed out for the 3dm2 ebuild. I'm not > complaining, but just trying to point out that evidently there are ebuilds > already in portage that don't meet the standards being used to review new ebuilds. We are trying to prevent such things happening in future, because it is bad thing QA-wise and we don't wont more badly coded/broken ebuilds to get into portage. Thanks for understanding and also thanks for pointing out the problems with sys-block/tw_cli, I'll file a bug about it.
It's better to use unpack rather than calling tar manually. This lets us use unconventional tar implementations cleanly. And yes, the tree is of, uh, varying quality... The hope is that by enforcing higher standards for things going in, we'll slowly get the average overall quality up. It's better not to use existing bad code as an excuse for adding more bad code.
(In reply to comment #10) > 1/ There are still problems w/ indenting in DOWNLOAD_URL and SRC_URI. > 2/ einfo " " is not needed, just plain einfo will do the job. ;) > 3/ You should add || die "uncompressing xxx failed" or to those tar xzf lines in > src_unpack() ; why upstream tarball contains another gzip-ed things goes beyond > me :) 1. I misunderstood your point about indenting/spaces. The DOWNLOAD_URL and SRC_URI lines are now indented for all but the first line. 2. I've changed the einfo as directed 3. I've added the || die "..." to the tar commands. I agree that it's odd to have a tgz contain other tgz files, but the tgz file is packaged by 3ware and how it's packaged is not within my control. Since their license requires that the user download the file from their website, I'm stuck with their method of packaging... :) > We are trying to prevent such things happening in future, because it is bad > thing QA-wise and we don't wont more badly coded/broken ebuilds to get into > portage. > Understood, I thought I was doing the right thing by copying an existing ebuild. This is my first ebuild submission, so thanks for having a little patience with me... :) > Thanks for understanding and also thanks for pointing out the problems with > sys-block/tw_cli, I'll file a bug about it. > No problem, I just thought I'd relay why the ebuild had some of the original errors you pointed out.
(In reply to comment #11) > It's better to use unpack rather than calling tar manually. This lets us use > unconventional tar implementations cleanly. > I tried several variants using the unpack function. From what I can tell, unpack requires that the file being unpacked is in ${DISTFILES}, which is not the case for this ebuild. Since the user must download the tgz file from the 3ware website, I'm stuck having to deal with how it's packaged, which is embedded tgz files... I'd be happy to change to unpack if you can educate me how this should be coded. > And yes, the tree is of, uh, varying quality... The hope is that by enforcing > higher standards for things going in, we'll slowly get the average overall > quality up. It's better not to use existing bad code as an excuse for adding > more bad code. Understood and a good plan of action IMHO...
Created attachment 67041 [details] 3dm2-9.2-r2.ebuild
jeff if you look at the sun_java ebuild's they have manual download only, you just put the program into distfiles and then it can be taken care of from there by the ebuild. A similar strategy should be applied to this one. Once its in distfiles, the emerge process can unpack anything within fairly easily.
(In reply to comment #15) > jeff if you look at the sun_java ebuild's they have manual download only, you > just put the program into distfiles and then it can be taken care of from there > by the ebuild. A similar strategy should be applied to this one. Once its in > distfiles, the emerge process can unpack anything within fairly easily. Joshua, unless I'm missing something, I think this ebuild already does that... The ebuild is fetch restricted and the user must visit the 3ware website and click through the EULA, download the tarball (tgz), and place the tgz into ${DISTFILES}. The problem is that the tarball as distributed from 3ware contains three tgz files, so the unpack of the distfile results in three additional tgz files in the portage work directory. I was unable to make the "unpack" portage function work with these tgz files. A quick review of the unpack function in ebuild.sh led me to believe that unpack only works on files in ${DISTFILES}. Am I missing something or doing something stupid? If so, can you elaborate on how the unpacking of the tgz files can be accomplished with the unpack function? Thanks, jthomps
i updated the ebuild to use the current release from 3ware which is 9.2.1.1. this ebuild works at our site for x86. there are also binaries for amd64, which should also work. i will attach the new ebuild, the the default config file and the init script.
Created attachment 68585 [details] the ebuild for 3dm2 9.2.1.1
Created attachment 68586 [details] default config file
Created attachment 68587 [details] init script
Created attachment 70772 [details] ebuild for version 9.3.0.1 New ebuild for v9.3.0.1. There is only 1 download for 32 and 64 files now so fixed it to account for that. Made the downloading a little easier basicly stolen from the tw_cli ebuild. Newer version of 3dm2 only works for https on 32bit so fixed einfo about that. Removed dodoc version.txt since it wasn't inclused in the .tgz file. If there are any problems please make notes i will fix what i can.
the 9.3.0.1 ebuild works fine for me
Hi, after downloading the 3ware tar file, I noticed that the filename downloaded from 3ware is: 3DM2-Linux-9.3.0.1.tgz and the latest ebuild expects a file named: 3dm2-linux-9.3.0.1.tgz I suggest that the ebuild be modified to match exactly the filename downloaded from the 3ware site or at a minimum, notify the user of the requirement to rename the file after downloading. -- jthomps
Created attachment 70865 [details] 3dm2-9.3.0.1-r1.ebuild This ebuild uses the filename 3DM2-Linux-9.3.0.1.tgz which matches the actual filename downloaded from 3ware.
Hi, 3dm2-9.3.0.1-r1.ebuild worked for me but I had to convert windows style end of lines using this : tr -d '\15\32' <3dm2-9.3.0.1-r1.ebuild > 3dm2-9.3.0.1-r1.ebuild.unix mv 3dm2-9.3.0.1-r1.ebuild.unix 3dm2-9.3.0.1-r1.ebuild
Created attachment 79308 [details] update to 3dm2-9.3.0.3
New version 9.3.0.4 Release Highlights * Support the new 9590SE controllers (x4 PCI Express controller) * Support the new 9550SX-16ML controller * Support new RoHS compliance (lead-free) controllers * New Feature: Boot LUN A ebuild bump works.
Please update the ebuilds to the current version of the tw_cli ebuild, and resolve the issue I noted in the earlier bug (60690) - specifically requesting that somebody find a way to disable the daemon overwriting it's config file the whole time. Until the config file issue is resolved, this should not be commited to the tree. *** This bug has been marked as a duplicate of 60690 ***
