Bug 324013 – app-forensics/samhain ebuild petulantly dropped from tree

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description fsykle 2010-06-14 20:53:16 UTC]

In http://bugs.gentoo.org/show_bug.cgi?id=150091 dacook provided a sufficient response for the uninformed/non-substantive bug to be closed (there was no evidence that the ebuild failed, or that the package was installed in non-working form, or that even one gentoo admin was in panic), or a _substantive_ response, not for the unsupported action to proceed.  

This is an effective ebuild installable _as is_. 

If an administrator/installer is serious-enough to want further services, such as keyed binaries, stealth, and extensive file configurations, they should be able to figure out how to set KEY_FPR and EXTRA_ECONF in /etc/portage/env. 

To not recognize that is to discount the very core of the tools that support the usefulness of the gentoo package tree.

Sure, a better package _could_ be written. And that language improved (the thrust of the message is important for inattentive installers to understand). But there are few ebuilds, even among core, that would survive such a test.

Restore to tree.


Reproducible: Always

Steps to Reproduce:
emerge samhain
Actual Results:  
emerge: there are no ebuilds to satisfy "app-forensics/samhain"


Expected Results:  
Calculating dependencies ...

[Comment 1 Jeremy Olexa (darkside) (RETIRED) 2010-06-14 21:02:00 UTC]

maintainer-wanted, like bug 321253

Feel free to take it to the sunrise overlay, as multiple people suggested on the -dev mailing list. http://archives.gentoo.org/gentoo-dev/msg_67f31d06d4747a011643714fcac07f22.xml

*** This bug has been marked as a duplicate of bug 321253 ***

[Comment 2 fsykle 2010-06-14 23:21:54 UTC]

No, this is not a duplicate of bug
http://bugs.gentoo.org/show_bug.cgi?id=324013. Specifically, this bug, bug 324013 reports that the ebuild worked fine. Bug 324013 is missing details, which I've asked for.

The separate topic is the logic for shifting to sunrise. There was no confirmed
bug to address, therefore the move didn't qualify on that grounds. Which would
also moot those ground for "maintainer-wanted". 

That leaves for a justification only "permanently keyworded". But how does it
serve users to remove a testing package that's still in testing yet has no
confirmed bugs? For users wishing to go ~arch it's working fine. Now, for those
very same users, it has to go in overlay. Blah.

It is an entirely different case, and helpful to users, when an arch package
goes ~arch. 

And, btw, even if a maintainer had stepped fwd and satisfied the nonsense
editorial, the package would still be ~arch for quite a while, since,
obviously, there'd been no effort in the herd to complete the testing (or even
to see if the ebuild comment impacted the build).

It's just a mistake to remove it; just put it back in the tree. You may have to
remove it later ... but on sufficient grounds.