> I fail to understand why the portage developers would refuse to > accept a patch that actually improves something (without causing > major regressions i.e.). If they do refuse such a patch (for > political reasons), then we have a serious problem. However, based on > past experience with the portage developers, I doubt this would happen.
Again, portage's lack of design isn't exactly conducive to accepting features. Having said that, it's taken this long to even get its behaviour documented (see PMS). Now that the spec exists, anyone can write a tool to reach the spec. > I base that on the fact that all developers are more or less > "equally" capable of making a technical decision. Maybe I am wrong. Less than 1% of gentoo developers interact directly with portage internals. So, provided the other 99% don't have to drastically switch how they interact with the development tool (and provided the users don't have to switch how they interact with the package manager), it doesn't matter much what's under the hood, does it? Surely, things like compatibility symlinks and such would go part of the ways to alleviating that sort of pain. As for being equal to the task of making the decision -- I'm certainly not. There are definitely developers who are more intimate with that area of development (even outside the portage team) whose opinions would weigh a lot heavier than mine, as an example. > I wasn't indicating that a "popularity" contest should be held, > because I trust the developers will cast their vote only after > *technically* evaluating the options. I also don't think it's fair > for a small minority of developers to make the switch on behalf of > the rest of us, which is why I mentioned a number like "50%". An > election is not always political ;) See above: not every developer is technically capable of evaluating the underpinnings of the tools we use. For most of us, those underpinnings do not matter. > Agreed. But if so many of us do think that there are better package > managers out there that do a magnificent job of utilizing the tree, > then I fail to understand why no-one is seriously considering a switch? Well, you can take some of the QA people who actually use pkgcore and paludis based tools to do what they do. You can also take the fact that Gentoo developers are actively involving themselves in pkgcore and paludis developments. You can also consider the fact that the council has asked for the PMS in order to present the community with a clear picture of current behaviour, expected behaviour and future behaviour of the package management we have. From there, it's not a big jump to then choose an alternate as the one that most adheres to the spec and make that one official, surely? Just because there is no widespread concerted effort to switch does not mean that there is no impetus to switch or that nobody is considering it seriously. The fact is that people are, we're just all in the exploratory stage still. > Ok, I'm sure a lot of us agree on the fact that portage is > technically outdated and is Gentoo's own "Frankenstein". Time for a > replacement, but what do you think would be the repercussions of > proposing something like that? If they are not catastrophic, might I > initiate such a proposal? It's probably a little early to initiate such a proposal, seeing as the PMS is still undergoing review. Why don't we just let the current course of events continue, instead of trying to force any specific issue? I'm sure that if the council decides to initiate a project to seriously pursue replacing portage as the official package manager, they will take into account these repercussions of which you speak. At the very least, you can bring them up at that time. I'm probably not the most qualified to speak on this subject, but I assume Ciaran and Brian and their respective teams both have ways (or can quickly think them up) to make the transition easier, should it come up. But again, it's probably a little early in the game for that. Thanks, Seemant
signature.asc
Description: This is a digitally signed message part
