| Summary: | Unmask or at least leave in portage app-admin/webmin | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | georgia_tech_swagger <gts> |
| Component: | New packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | a3li, bugs.gentoo.org, gaurdro |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
georgia_tech_swagger
2010-08-29 22:35:54 UTC
The QA concern is much deeper than that message implies. the term 'live filesystem' is used for the real filesystem during the emerge process. for more information please look here [0]. [0] http://blog.flameeyes.eu/2010/08/20/there-s-something-about-webmin (In reply to comment #0) > That is webmin's PURPOSE in life... dealing with administration tasks of a > server. Obviously that means it's getting deep into the FS. If this is so > egregious then leave it masked (along with coreutils and that nasty rm tool > that touches live filesystem?), but don't remove it from portage as some people > such as myself still find it very valuable. > It seems you have not understood the underlying issue which is especially the ebuild subverting the sandbox. As long as there is no maintainer to step up and fix the ebuild, the package should not stay in the tree in the interest of your and other users' systems. You can always keep it in a local overlay. The Gentoo wiki contains an article detailing the setup. Thank you for your understanding. (In reply to comment #2) > (In reply to comment #0) > > > That is webmin's PURPOSE in life... dealing with administration tasks of a > > server. Obviously that means it's getting deep into the FS. If this is so > > egregious then leave it masked (along with coreutils and that nasty rm tool > > that touches live filesystem?), but don't remove it from portage as some people > > such as myself still find it very valuable. > > > > It seems you have not understood the underlying issue which is especially the > ebuild subverting the sandbox. > As long as there is no maintainer to step up and fix the ebuild, the package > should not stay in the tree in the interest of your and other users' systems. > > You can always keep it in a local overlay. The Gentoo wiki contains an article > detailing the setup. > > Thank you for your understanding. > Ironically, it appears you do not understand the concern in the community on this. The mask warning does not specify that the *ebuild* is at fault here (as is suggested in the link provided in comment #1 ...) so the warning makes it sound like Webmin itself is at fault (which unfairly puts judgement on the quality of the upstream maintainers). If you are considering removing the package because the ebuild is poorly built and not maintained then at least *explicitly* say so in your warning. I still think it is foolhardy to remove such a well-established software package the package completely just because of a less than perfect ebuild (internal Gentoo issue) as opposed to just poor quality software (upstream issue). What is the harm in leaving the package masked in the tree, noting that the ebuild is problematic and then (*gasp*) waiting for a maintainer to come along and clean up the mess? If Webmin bumps up a major version number (or a few minor versions), then I can see it getting pulled due to a gross lack of package maintenance but pulling it because of a poor ebuild (and, by the sounds of things, a poor maintainer that "fixed" that ebuild) is somewhat antithetical to the Gentoo philosophy stated on the main page: "Every user has work they need to do. The goal of Gentoo is to design tools and systems that allow a user to do that work as pleasantly and efficiently as possible, as they see fit. Our tools should be a joy to use, and should help the user to appreciate the richness of the Linux and free software community, and the flexibility of free software. This is only possible when the tool is designed to reflect and transmit the will of the user, and leave the possibilities open as to the final form of the raw materials (the source code.) If the tool forces the user to do things a particular way, then the tool is working against, rather than for, the user. We have all experienced situations where tools seem to be imposing their respective wills on us. This is backwards, and contrary to the Gentoo philosophy." ... so please explain how it is "pleasant and efficient" to remove software from the tree that is well-established and has no issues major issues in and of itself and then further suggest users set-up (and maintain?) their own local overlays. If you are still intent on removing this package from the tree then please, at the very least, explicitly state that the *ebuild* is violating QA policies and that package is being removed due to lack of a maintainer (I would volunteer to fix things if I knew enough about developing ebuilds but, sadly, I do not ... yet). (In reply to comment #3) > Ironically, it appears you do not understand the concern in the community on > this. I can very well understand you want the package to stay because it works for you. However there are several interests to be considered here, not only yours. > The mask warning does not specify that the *ebuild* is at fault here (as > is suggested in the link provided in comment #1 ...) so the warning makes it > sound like Webmin itself is at fault (which unfairly puts judgement on the > quality of the upstream maintainers). > That's a point. Should be fixed now. > What is the harm in leaving the package masked in the tree, noting that the > ebuild is problematic and then (*gasp*) waiting for a maintainer to come along > and clean up the mess? > [...] These QA policies are there to avoid breakages by forbidding certain things that have a high probability in breaking things. Letting people run into known or likely pitfalls is something that noone wants, I do think that includes you and all the other people who want to use webmin on Gentoo. > > ... so please explain how it is "pleasant and efficient" to remove software > from the tree that is well-established and has no issues major issues in and of > itself and then further suggest users set-up (and maintain?) their own local > overlays. > It's simply the lesser evil in that situation. But why don't you use this situation to change things for the better? There are obviously some people who want to use webmin, so team up because here's *your* chance to do something for the community. I do explicitly not mean starting endless discussions about keeping the broken ebuild in the tree. What I mean is: There was a developer on the linked blog entry above who offered help. I'm sure you can work together with him on getting a better ebuild. You do need to have an overlay, why not make that a public webmin overlay? And when the day comes that the ebuild is properly and safely installing webmin, you can submit it again, and maybe someone of you even wants to fully maintain it in the official tree. *That* would be a real improvement over the current situation. Continuing to argue about this is not (and a waste of everyone's time). NB: I'm not with QA; I'm just some dev who wanted to avoid that this bug is closed as INVALID without any comment. (In reply to comment #4) > (In reply to comment #3) ... I thank you for the prompt reply and though I disagree with some of your premises (e.g. that I posted for my own consideration) and notice that you mention that you are not personally on QA, I can certainly respect QA's circumstances (more maintenance needed done than available resources to perform that maintenance in a "timely" fashion) should they still choose to pull it when the day comes. I just judge the pulling of the package as unnecessary (if some fool blindly unmasks a package w/o researching the reason behind the mask, it's their own fault for whatever ill consequences may befall the system). It was my impression that "hard masking" was intend for situations such as this anyway so I could not see how it would be necessary to pull the package entirely. Additionally, I would love nothing more to help in fixing this for the community but I currently lack both the sufficient knowledge to building quality ebuild scripts (as opposed looking at some that work and "guessing" my way though it) and the available time to do so (any free development time I do get I try to primarily attribute to the project to which I am documented as a developer/maintainer and help elsewhere as available). I have webmin in my overlay. I try to keep it current since I use webmin at work for administration of my gentoo network. http://github.com/drescherjm/jmdgentoooverlay With that said I have not been as active on this lately because programing is my primary job function (at work) and I am quite busy at that.. "That is webmin's PURPOSE in life... dealing with administration tasks of a server. Obviously that means it's getting deep into the FS. If this is so egregious then leave it masked (along with coreutils and that nasty rm tool that touches live filesystem?), but don't remove it from portage as some people such as myself still find it very valuable." +1 ! "leave it masked but don't remove it from portage as some people such as myself still find it very valuable" |
