On 30 March 2017 at 12:00, Michael Schwendt <mschwe...@gmail.com> wrote:
> True, and I haven't claimed the opposite. You need to slow down, IMO, > as it seems you've misunderstood me completely. It's really just that > whereas some packagers have removed /usr/bin/env from their packages, > others have refused to do that, and neither the Review Guidelines nor > the Packaging Guidelines contain anything about removing /usr/bin/env. > In various reviews that would make it more difficult to convince package > submitters, and some would argue endlessly about wanting to keep > /usr/bin/env. > I see more and more issues related to FPG. And most discouraging is not what is inside FPG because I can agree with most of the advices in this document Seem some packagers are using it almost blindly. And we are not talking about few but something like almost majority. Example. Few days ago I've submitted changes to slang to remove build and package static libraries and couple of other minor fixes. https://bugzilla.redhat.com/show_bug.cgi?id=1436909 Most of those changes so far have been refused and and for some reason packager found even that in submitted patches I doing more than it is described. I've added as well after initial submission patch which removes using env on calling slsh. All those issues are some results of miscommunication and I'm not going to blame anyone. Seems problem will be here with one very minor thing about how to implement Obsolete rule which should remove slang-static from the system. This single line has been changes to versioned Obsolete rule. My first reaction is written in the comment in this ticket. After this I've started asking myself why it was changed this way. And I found why .. Because in FPG there is no point about how to add rules about permanent remove of the package when like in case all static subpackages which I'm going to introduce. In absence of such detail is used what is already mentioned about using Obsolete to change name of the package. OK. After I found that in this case it may be matter of miscommunication simple I've asked myself "so how it is with using it Obsoletes in other Fedora specs?" I was really surprised that ~95% of the Obsolete lines contains versions. There are even more bizarre things here because in may specs it is possible to find not fixed versions but versioning using %{version} and %{release} macros. 100% of Obsolete rules about static packages obsoletion are with versions. Some of them are with %{version} and %{release}. Obviously it is wrong because if decision about remove permanently doesn't matter which one version wa found decision not tolerating such package with Fedora packages has been made and adding versions to Obsolete rule is pointless .. "Roma locuta, causa finita". Again so far please do not read above as blaming anyone like those people Because my teachers always been telling me that "why? questions are most important questions I've started digging deeper and I think that I found at least two if not three possible explanations of above. I'm to shortly observing Fedora forums and IRC channels to point on exact explanation as correct, It is some possibility that it is possible to explain what I see in other way. Obviously using FPG has some roots in trying to formalise some changes. Such pendulum of rules is moving between two points which are: 1) trying to stop some very stupid changes in some packages 2) trying to enforce spreading some exact well tested patters about how to treat some resources in packages So .. Explanation 1 ========== Somewhere on the past is was some number of bad cases with some changes in packages that it was introduced some non written policy (not a guideline but exactly *policy* which has stronger connotation than guideline) to not do anything what is not described in FPG. Pressure on some unwise packagers to use strictly using FPG was so strong that it blocked mids many other packages to the point that they are refusing to implement some well technically justified changes. So here is result of some fright factor result. Explanation 2 ========== Some packages are inexperienced and not sure of own skills and because they are not sure about some proposed changes using FPG is only possible to use option. So here we may have some kind of lack of confidence or experience/knowledge factor. Explanation 3 ========== Some packagers are forgetting that G in FPG acronym stands for Guideline to a Law or Policy. Whatever what is written in Guideline will be very hard strictly use across 100% of packages because all rules of packaging even within limited space of all possible correct spec files will take probably +10 times than current size of FPG. So here we may have some kind of lawyers or strict believers/followers factor. In case 1) I can easily point on many specs which are using things not described in FPG. So at least some people are correctly understands that "guideline" means set of advices which really gives them flexibility of making own decisions using own expertise. In case 2) people some lack of technical expertise should be asking on the forums for help. Problem is that within last month so far I did not spot anyone here or on IRC with this kind of questions. I'm really sure that such people are .. In case 3) it is easy to trow baby with bath stopping necessary changes. Because what happens with specs will require some some set of rules which will be used only with few if not only one spec file. Real explanation is probably between those three points and as I wrote it is possible probably to add more such points. In other words above is not about some technical aspects but is more about sociology or psychology of the groups. You are asking me to hold on. OK I can do this. I have only two questions: 1) on what or who I should wait? 2) how long? (ruffly) So far in last month I've been able to propose at least few changes which may affect thousands packages. Those changes are relatively simple or even trivial for experienced rpm packager like me. I can do tenths such changes a day in my free time. This is not a problem. Problem is how to introduce such changes with minimal bureaucratic overhead? How I think that such cases like mine should be tackled? It should be simple if not simpler than below description. Someone who is proposing something to change should: - on the forum someone should give the green light to start - crate ticket with problem description - If something needs to be documented in FPG bugzilla IIRC has already possibility to work on some necessary documentation related to request - max 2-3 cycles peer reviews - voting or approval from someone who is maintaining FPG - start of integration necessary changes in originally listed packages. Progress is reported (buy someone who initiated change and/or other packagers) under initial ticket to have proper view of the state whole work. Just please do not send me to the /dev/tree or ask me to "wait on the Godot". This is not something what I can try to "process". kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
