Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hello; I'm just a gentoo user who has been lurking for a while trying to find a useful way to help my linux distro. Gentoo was recommended to be as a good way to get into linux and to rapidly understand the difference between the way linux works and windows works. I have to say that for the two years of my university life that i have used Gentoo for it has taught my a lot. Now i have never had a problem with portage my self, but since this thread is in existence there are some definite issues. Myself as a user would very much have to support Duncan's post below and as a Computer Science grad would have to say that it makes sense to clearly define a PMS which should be swappable 1:1 with any other PMS. To help new users the basic command set should also be the same, tho of course each PMS can have its own advanced features. Finally my own personal view of this matter; Gentoo should have and support its own package manager, it makes sense since one of the key advantages of Gentoo is to just have to packages you need with just to support you need i.e. USE flags. Since this is a key goal of the gentoo project it makes sense to provide a 'default' PM which abides to the PMS. It also means that there will always be a secure, monitored, distribution maintained package manager which would guarantee the distributions basic functionality. Well there is my 'users' point of view; As a quick aside, could someone point me in the right direction to help out with Gentoo, I've got some skills in C and C++ tho my main language is Java, but I'm a quick learner :P Duncan wrote: I keep seeing references to an official package manager. Clearly, at this point, it's portage, in part because there was no other practical reference for deciding whether the ebuild or the handling of it was broken. If it worked in portage, therefore, by definition, it was fine. (Well, with certain exceptions where portage was held to have bugs, but whether it was a bug in portage or not had to be decided before one could then rule on whether it was a bug in the tree or not.) However, now that PMS is finally about to provide what should be a definitive description of current generation package behavior, with the announced intention to update this with new versions into the future as required, the dependence on portage as the reference will soon be going away. The announced intention for this, among other things, is to allow alternate package managers, such that it can still be clear when it's the package broken and when it's the package manager. So far, so good. However, with such a definitive package behavior reference, the question presents itself, with what looks to be several possible alternatives waiting, why must Gentoo have an official package manager at all, and indeed, what purpose, other than name recognition, does maintaining such an official manager have? I'd contend that with an appropriate package/tree spec, as soon as we have multiple package managers meeting that spec, then we /don't/ /need/ an official package manager. Perhaps one /recommended/ by default in the documentation, sure. Perhaps one that ships on the official Gentoo LiveCD installers, sure. However, all this arguing over official package manager is worthless, IMO. Let the alternatives each stand on their own merits, just as we do with all sorts of other choices, optionally with one recommended for newbies who don't have any reason of their own to prefer one over another and likely with one used to build official media, but without any of them recognized as the /official/ package manager, because there's simply no continuing need for such a thing, once the extents and limits of acceptable package behavior at a particular API level has been appropriately speced out. If this approach were taken, it wouldn't have to affect releng much at all, certainly short term, since they could continue using portage, which is assumed to continue to be one of the recognized and accepted alternatives. Longer term, it would only as they found reason to switch to other alternatives, and if they didn't find such reason, well... It would affect bugs very little as well, since there are already bugs where it ends up being a package manager regression, only now, such regressions would be measured against the package spec, rather than against past behavior of any particular package manager (except as necessarily encoded in that spec, for the first version, anyway), and there'd now be a definitive way to say for sure whether it was the package manager or the package. Documentation, there'd necessarily be some adjustment. However, the documentary focus could remain on the recommended package manager, referring to the individual manager's documentation if they'd made a choice other than the recommended choice. Certainly, it
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: However, now that PMS is finally about to provide what should be a definitive description of current generation package behavior, with the announced intention to update this with new versions into the future as required, the dependence on portage as the reference will soon be going away. The announced intention for this, among other things, is to allow alternate package managers, such that it can still be clear when it's the package broken and when it's the package manager. From what I've read of the PMS, it currently only describes the input format it would accept (namely the format for ebuild files and their contents). This question can be delayed until the PMS defines the operation of the package manager, including but not limited to the recording of installed package data. If the package managers do not agree on which packages are installed or how to uninstall them, then they are not yet interchangeable. I apologize if this point has already been raised elsewhere in the thread. I try not to get involved in threads like this, but accidentally read a reply and thought this might be a valuable response. Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGD6/0u7rWomwgFXoRAiT9AKCV/+YGLba3owSWEt/cbOPbyC3YrgCfbboE +oqnTwPBGzD7ORY15VwOxoo= =I3ta -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: The point being, however, that all this quarreling about official package managers doesn't /really/ have to happen. [...] I just don't see why so many are spending so much time arguing over it, when regardless, people are going to make their choices, and official status won't matter so much when people do so, because the package spec and what works is going to be the defining factor, not some official blessing, except indirectly as that affects further package spec updates. I agree that the title official is nothing more than a title or label and will most likely be applied to the most common/popular manager. I think the reason for the discussion is that arguably Gentoo has been goal-less or at the very least major-project-less, and developers with vision are nervously looking for the direction to push the project. Personally, I'm very happy with Gentoo as is, it's flexible, I can add the packages I might find when browsing the web and it does everything I need. I don't need a major direction, or a big change, or an upheaval, or pretty much anything else, and I believe many of the less vocal developers feel similarly. However, for those that are looking for a change (and sunrise and seeds both seem recent evidence that a body of developers are looking for a change), then I think the alternative package manager is a nice big area with big uncertainty, given that it's well developed source-based package management is arguably the unique selling point of Gentoo. I think if someone were writing a new portage that simply took over from the old one one day, there would be nowhere near as much discussion. Therefore, the issue at the heart of these threads is the possibility of splintering of the project. There are quite clearly two sides. Those that would like to see multiple package managers: their reasoning is that they'd like to offer an alternative, with features and designs that would be difficult to integrate into the existing code, and some decisions that would break with the current design (albeit slightly). The other side doesn't necessarily fear another, better package manager, but fears that allowing multiple package managers will start to cause incompatibilities and will divide both the user group and the developer group. Overlays are a feature capable of this division, and already it's given rise to the seeds idea, which again met with the same dissent: that of divided time and resources spent on a number of smaller Gentoos, each with less popularity, less time devoted to each, and the difficulty of re-integration with the main branch. Nobody actively wants to break the main tree, but no one has yet figured out a way of ensuring that users do not encounter disruption if they decide to use a different package manager. The PMS is a step to overcome this by defining a standard, or interface, to ensure compatibility. So how can we smooth the way between the two sides? The best I can come up with is a more complete specification. One that includes both the package format, and the local state required to store data. The Pros for this, are that package managers could become interchangeable, to the point that it would never matter which package manager were in use at the time. The cons for this idea, are that it would slow down the development, changes and feature additions to the various managers, as the changes must first pass through the specification and then finally be implemented. We've already seen (with the introduction of Manifest2) that changes to the tree and distribution mechanism are slow at best (I believe manifest signing is over two years old and still not in place for every package?). Requiring adherence to a specification, and maintaining that specification will be even more difficult and slow, but it would allow both sides to move on, and work together towards the new direction. So now the question is, are we willing to accept the cons for the pros, or do we need to find a different solution. If not, then other package managers should invest their time in ratifying a specification quickly, so that they can get down to coding to the specification. Also, those against a new manager, should get down to agreeing the specification so that managers with the possibility of fracturing are bound within a framework of acceptability. As I see it, that leaves both sides working towards the same direction, and should give impetus to both groups to come to a common point as fast as possible. If not, then probably we should return to the drawing board, but I concur that bickering and worrying about the future without pinpointing the problem and trying to tackle it, is far more futile than working towards a viable solution... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux)
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
On Sat, 31 Mar 2007 23:27:19 +0100 Steve Long [EMAIL PROTECTED] wrote: Stephen Bennett wrote: ... Gentoo developers can take the latest release of said package manager and continue development from that. That's the wonderful thing about the GPL, no? Too late for all the affected users tho. Point is it's a major security hole which no sane organisation would even consider for mission-critical code. Do you really think anyone checks every last line of code in every release of every system package? Sneaking in a check for /etc/gentoo-release with a time-delayed nasty into a widely used package wouldn't be particularly hard for anyone serious... Heck, getting oneself recruited under a pseudonym and sneaking some very nasty global scope code into the tree wouldn't be particularly hard for anyone serious... These arguments are getting weaker and weaker... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
On Sat, 2007-03-31 at 23:39 +0100, Steve Long wrote: Seemant Kulleen wrote: That's uncalled for. There's no need to get nasty. I applaud your intent, but feel it would have far more effect on the atmosphere if applied to a few of your devs, rather than users who employ milder terms? It just seems knowingly unfair, and I don't believe that is your purpose. Not getting into this. If your intent is to undermine, please do it privately. If you're just trying to be inflammatory (as you seem to be often), please put a stop to it *NOW*. Like I've said before, just because you know how to type an email and send it, doesn't mean you *should*. You can check my posts to see me address anyone getting out of hand. Thanks, Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
On Saturday 31 March 2007, Ciaran McCreesh wrote: Steve Long [EMAIL PROTECTED] wrote: Too late for all the affected users tho. Point is it's a major security hole which no sane organisation would even consider for mission-critical code. These arguments are getting weaker and weaker... security based concerns in this sort of scenario can be turfed ... i dont think it's a relevant concern compared to the other issues at hand -mike pgpgzYCi2OCNN.pgp Description: PGP signature
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
Michael Krelin wrote: The question is whether scripts that, say, parse emerge -pv output have to carry on working. I think this requirement would put portage itself in quite uncomfortable situation. It's a non-issue imo; it's up to script authors and maintainers (aka users) to keep up with whichever tools they choose, cf Bash 3.2 regex changes. If it's a useful script, it'll get updated. I think the same applies not only for different portage versions, but for various package managers too. There may be some parts of the output strictly specified, but otherwise it's like indeed forcing all sendmail-compatible mailers provide uniform mailq output. Love, H -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
On Sunday 01 April 2007, Seemant Kulleen wrote: On Sat, 2007-03-31 at 23:39 +0100, Steve Long wrote: Seemant Kulleen wrote: That's uncalled for. There's no need to get nasty. I applaud your intent, but feel it would have far more effect on the atmosphere if applied to a few of your devs, rather than users who employ milder terms? It just seems knowingly unfair, and I don't believe that is your purpose. Not getting into this. If your intent is to undermine, please do it privately. If you're just trying to be inflammatory (as you seem to be often), please put a stop to it *NOW*. Seemant: Please, please, learn a bit about British English idiom. Your gross over-reactions to both what I, and Steve Long, wrote indicate that while you have interpreted our words precisely, you have completely failed to appreciate the overall nuance of meaning in either message. Neither of which carries anything like the level of inflammatory obloquy which you seem to have deduced from them. I don't know who first uttered the phrase: We are separated by our common language. or words to that effect, but I see the effect of it in postings to this list time and time again. It's a shame. Like I've said before, just because you know how to type an email and send it, doesn't mean you *should*. Indeed! You stole my very words! A case for the thought police I do believe! You can check my posts to see me address anyone getting out of hand. Not today, thank you. For those readers who might have difficulty with this message, please rest assured that the second two paragraphs are intended to be jocular, and consult Princeton University's Wordnet system for precise meanings. -- CS -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
Duncan wrote: A segment of an already minor segment (certainly currently, tho that /may/ eventually change), not likely to be something that can reasonably be characterized as benefiting Gentoo as a whole, at least in the near to medium term, and beyond that, well, things remain up for grabs. Hear hear, although i do tend to agree with Mr Goodyear's assessment; if not Gentoo, then who? And hasn't Paludis improved Gentoo's QA already? At the end of the day, some poor student is going to volunteer to do this because they find it interesting (if it were to go ahead.) In that case, I'd peronsally say let them. But I don't know the ins and outs of the Council's thinking obviously. And TBH you lot voted them in to make this kind of call. Why not let them? Because IMHO it's not their place. We have a Summer of Code Project. We know there are issues. We plan to address them. The council is the *last place* to take issues in my mind. Think Supreme Court (bad analogy but whatever). If you have a problem with the way the summer of code is handling (or perhaps will handle) this situation feel free to talk to us, e-mail us, find us on irc ([EMAIL PROTECTED] and #gentoo-soc respectively). rant I get really irritated when people just say 'well go talk to the council' when they haven't even talked to the project members, or the project lead, or god forbid, the ombudsman. /rant -Alec -- gentoo-dev@gentoo.org mailing list
