Re: [gentoo-dev] [soc] Python bindings for Paludis
On Tue, 03 Apr 2007 10:10:30 -0700 antarus [EMAIL PROTECTED] wrote: I think there is a difference. Take the issue with the ubuntu installer that left the root password in a log in /var. Who was responsible? Ubuntu. Why? Because it's their installer, their project. And who would be responsible if someone put a back door in apt? Ubuntu or Debian? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Alec Warner wrote: The fact that Gentoo can continue with the codebase is irrelevant. I think moreso the fact that a particular Package Manager would be the 'Gentoo Package Manager' means in my mind that Gentoo is responsible for said Package Manager. If someone were to slip evil code into said Package Manager and Gentoo released it; that would be bad. Note that with Portage, Gentoo could pull svn access for any individuals who commit such code. Gentoo have no gaurantee of that with an externally managed Manager as Gentoo has no control over the source repositories. If, by your comment above, Gentoo should maintain it's own branch of said package manager to insulate itself from issues such as the security issue defined above; well I think that may be one way to address the problem presented by Seemant. Come on, that's a bogus argument. By that logic, we should be maintaining our own branches of, say, sys-apps/shadow, since we don't control the upstream CVS repository. I think something that's installed in the base system set would also be perceived as something that Gentoo is responsible for, since we ship it in our stage tarballs, the basic building blocks of a Gentoo system. -- Mike Kelly signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Mike Kelly wrote: Alec Warner wrote: The fact that Gentoo can continue with the codebase is irrelevant. I think moreso the fact that a particular Package Manager would be the 'Gentoo Package Manager' means in my mind that Gentoo is responsible for said Package Manager. If someone were to slip evil code into said Package Manager and Gentoo released it; that would be bad. Note that with Portage, Gentoo could pull svn access for any individuals who commit such code. Gentoo have no gaurantee of that with an externally managed Manager as Gentoo has no control over the source repositories. If, by your comment above, Gentoo should maintain it's own branch of said package manager to insulate itself from issues such as the security issue defined above; well I think that may be one way to address the problem presented by Seemant. Come on, that's a bogus argument. By that logic, we should be maintaining our own branches of, say, sys-apps/shadow, since we don't control the upstream CVS repository. I think something that's installed in the base system set would also be perceived as something that Gentoo is responsible for, since we ship it in our stage tarballs, the basic building blocks of a Gentoo system. Except we aren't the authors of sys-apps/shadow. sys-apps/shadow is not a Gentoo project. I think there is a difference. Take the issue with the ubuntu installer that left the root password in a log in /var. Who was responsible? Ubuntu. Why? Because it's their installer, their project. We don't endorse things like sys-apps/shadow; we just happen to use it. If we say 'Package X is the official manager', then to me that implies endorsement. A package manager is a solid part of Gentoo. Source based package management is a huge part of what separates us from all other distributions, I think that has some meaning, if not to you than to many of our users. If there was such a security problem with the official manager, who is responsible? Gentoo. Even if it's not really 'our' project. Because it's our manager. Not any other distros, but ours. -Alec -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On 3/30/07, Mike Frysinger [EMAIL PROTECTED] wrote: a good topic for the next council meeting i think would be to start up a spec of requirements that a package manager must satisfy before it'd be an official package manager for Gentoo ... off the top of my head: - the main developers need to be Gentoo developers - source code hosted on Gentoo infrastructure - compatible emerge and ebuild binaries -mike The Comments of a Gentoo User Upon a Minor Point Made by Vapier The first condition you list is a sort of nativism that I for one would expect not to find in a successful copyleft project created on the Internet. Why should the code Gentoo uses be written by Gentoo developers? Nobody seems to have a problem with using someone else's C compiler and installation tools (gcc, autoconf, automake). Resistance to a package manager on the grounds that, It wasn't originally written by us! could perhaps push technical arguments that actually matter into the background. Sincerely, Christopher Covington -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 31 Mar 2007 20:02:28 +0200 Christopher Covington [EMAIL PROTECTED] wrote: The first condition you list is a sort of nativism that I for one would expect not to find in a successful copyleft project created on the Internet. Why should the code Gentoo uses be written by Gentoo developers? Nobody seems to have a problem with using someone else's C compiler and installation tools (gcc, autoconf, automake). Resistance to a package manager on the grounds that, It wasn't originally written by us! could perhaps push technical arguments that actually matter into the background. It seems to me that this is just vapier's way of saying I don't want ciaranm anywhere near an official package manager. Regards, -- Andrej -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 2007-03-31 at 20:16 +0200, Andrej Kacian wrote: On Sat, 31 Mar 2007 20:02:28 +0200 Christopher Covington [EMAIL PROTECTED] wrote: The first condition you list is a sort of nativism that I for one would expect not to find in a successful copyleft project created on the Internet. Why should the code Gentoo uses be written by Gentoo developers? Nobody seems to have a problem with using someone else's C compiler and installation tools (gcc, autoconf, automake). Resistance to a package manager on the grounds that, It wasn't originally written by us! could perhaps push technical arguments that actually matter into the background. That's not what he's saying. All those other things you mention are critical to a linux system -- ANY linux system, EVERY linux system, ANY distro, ALL distros, ANY BSD system, ALL BSD system, ANY BSD distro, ALL BSD distros, and more. They are, in other words, shared resources. RPM is another example of a shared resource. Apt might well be considered to be so as well. Portage, on the other hand, is not. It is, you see, part of the very identity of *this* distribution, and isn't quite shared by other major distributions. If portage, or a tool very much like it, becomes part of the larger community and shared by 2 or more *major* distributions, then your argument starts to hold water. Until then, I'm afraid it's a straw man. It seems to me that this is just vapier's way of saying I don't want ciaranm anywhere near an official package manager. Far be it from me to read spanky's mind, and may I say: far be it from you too. However, given my paragraph above (and prior emails in this thread from both vapier and me), I would say that your statement is inaccurate, at worse, but incomplete at best. The point being made, then, is that for an official package manager to exist *for Gentoo*, it needs to be under *Gentoo's* control. To make it more clear. If the gcc developers decided to stick some malicious code into gcc, it affects the entire linux community, the entire BSD community and would take out a few other communities as well. The effects are far reaching and shared by everyone. If an official package manager is outside of Gentoo's control, and the maintainer(s) of that piece of software decide to do anything malicious (examples: inject some dodgy code, remove documentation, take out access to the repository, etc) for whatever reason (say, they get pissed off at a few Gentoo people and decide that the entire Gentoo community can be painted that way), then Gentoo has now become a slave to those people. That, I'm sure you'll agree, is unacceptable. So, no, what vapier was saying (at least in prior emails) is that regardless of what package manager is deemed to be official, it needs to meet a minimum set of criteria, and one of those is that it needs to be housed on gentoo infrastructure and maintained by gentoo developers (and thus be accountable for their code). Please don't read anything into what I've said other than what I've said. Thanks, Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 31 Mar 2007 15:24:03 -0400 Seemant Kulleen [EMAIL PROTECTED] wrote: The point being made, then, is that for an official package manager to exist *for Gentoo*, it needs to be under *Gentoo's* control. Well, the source is open, and there are already enough Gentoo devs working on it, so it's not like Gentoo can't control what's being used. Let's say paludis does become the official PM for Gentoo. This would undoubtedly mean that (even more) Gentoo developers would be working on it, likely with Ciaran's (or anyone else without @gentoo.org's) contributions. How is that different from non-developers submitting patches to portage? Kind regards, -- Andrej -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 31 Mar 2007 15:24:03 -0400 Seemant Kulleen [EMAIL PROTECTED] wrote: To make it more clear. If the gcc developers decided to stick some malicious code into gcc, it affects the entire linux community, the entire BSD community and would take out a few other communities as well. The effects are far reaching and shared by everyone. If an official package manager is outside of Gentoo's control, and the maintainer(s) of that piece of software decide to do anything malicious (examples: inject some dodgy code, remove documentation, take out access to the repository, etc) for whatever reason (say, they get pissed off at a few Gentoo people and decide that the entire Gentoo community can be painted that way), then ... 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? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Saturday 31 March 2007, Andrej Kacian wrote: Christopher Covington [EMAIL PROTECTED] wrote: The first condition you list is a sort of nativism that I for one would expect not to find in a successful copyleft project created on the Internet. Why should the code Gentoo uses be written by Gentoo developers? Nobody seems to have a problem with using someone else's C compiler and installation tools (gcc, autoconf, automake). Resistance to a package manager on the grounds that, It wasn't originally written by us! could perhaps push technical arguments that actually matter into the background. It seems to me that this is just vapier's way of saying I don't want ciaranm anywhere near an official package manager. i'm glad i have people to tell me what i mean when i say things ... now i can focus on merely spouting fourth english language constructs and let other people interpret them. i do believe i just became an oracle. phear. -mike pgp54us7sWcBj.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 31 Mar 2007 15:24:03 -0400 Seemant Kulleen [EMAIL PROTECTED] wrote: To make it more clear. If the gcc developers decided to stick some malicious code into gcc, it affects the entire linux community, the entire BSD community and would take out a few other communities as well. The effects are far reaching and shared by everyone. If an official package manager is outside of Gentoo's control, and the maintainer(s) of that piece of software decide to do anything malicious (examples: inject some dodgy code, remove documentation, take out access to the repository, etc) for whatever reason (say, they get pissed off at a few Gentoo people and decide that the entire Gentoo community can be painted that way), then ... 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? The fact that Gentoo can continue with the codebase is irrelevant. I think moreso the fact that a particular Package Manager would be the 'Gentoo Package Manager' means in my mind that Gentoo is responsible for said Package Manager. If someone were to slip evil code into said Package Manager and Gentoo released it; that would be bad. Note that with Portage, Gentoo could pull svn access for any individuals who commit such code. Gentoo have no gaurantee of that with an externally managed Manager as Gentoo has no control over the source repositories. If, by your comment above, Gentoo should maintain it's own branch of said package manager to insulate itself from issues such as the security issue defined above; well I think that may be one way to address the problem presented by Seemant. -Alec -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Seemant Kulleen wrote: The effects are far reaching and shared by everyone. If an official package manager is outside of Gentoo's control, and the maintainer(s) of that piece of software decide to do anything malicious (examples: inject some dodgy code, remove documentation, take out access to the repository, etc) for whatever reason (say, they get pissed off at a few Gentoo people and decide that the entire Gentoo community can be painted that way), then Gentoo has now become a slave to those people. That, I'm sure you'll agree, is unacceptable. (ignoring [possible securty issues as per spanky's mail) Wouldn't that be solved if $other-package-manager folks provide full dumps of the SCM system they use? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Hi, Ciaran McCreesh schrieb: On Thu, 29 Mar 2007 22:47:46 +0200 Thomas Rösner [EMAIL PROTECTED] wrote: Other things I want from Gentoo right now depend on factors other than the package manager, too; prebuilt packages A package manager that supports a better binary package format (split out local metadata would be a good start) combined with a third party binary provider could deliver that with no tree changes. But then you'd need a tree of binary packages, which you'd only get with many users of your package manager, which would depend on official Gentoo adoption, which would depend on compelling other features, which would depend on having a way to get them into the ebuild tree without breaking portage. That's what I mean. I think you know that and that's why you did work on PMS, but then you point out features paludis has and portage hasn't repeatedly in a way that apparently builds up resistance in people here. Hm, perhaps you should let somebody else do the PR for paludis? :-) Heck, it's even doable with Portage's binaries, although according to a Gentoo-based distribution that tried it, your 30 minutes would be optimistic for -uDpv world... Yes. Also it's quite easy to screw up using the current format, nothing I'd recommend for heterogeneous environments. binary-breakage protection Funnily enough... That one can be done without tree changes too via something we're calling reparenting. There're some vague suggestions of roughly how to do it at [1]. [1]: http://paludis.pioto.org/trac/ticket/129 Now that'd be an interesting feature... *thinks about joining #paludis* Regards, Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, Mar 29, 2007 at 10:04:57PM +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 22:47:46 +0200 Thomas Rösner [EMAIL PROTECTED] wrote: Other things I want from Gentoo right now depend on factors other than the package manager, too; prebuilt packages A package manager that supports a better binary package format (split out local metadata would be a good start) Not really a huge gain; if you're attempting remote, you're better off with a single file for the entire cache anyways. If you're not doing remote, the few seeks required for xpak aren't killer. Granted, a cache can help, but it's design choice for the format. With tbz2, you can unpack if you're completely screwed manager wise; transfering binpkgs around doesn't require copying two files (as your ebin format does). it's even doable with Portage's binaries, although according to a Gentoo-based distribution that tried it, your 30 minutes would be optimistic for -uDpv world... Said derivative should look into adding remote binpkg v2 (solars work) into portage then. The slowdown isn't due to the format, it's due to the freaking craptastic implementation that snuck in. Short version, remote binpkg v1 (existing in portage) is designed around simply making the normal on disk repo sharable via apache/ftp/whatever, no mods/transformations required; goes without saying, what works for local access doesn't mean it's going to work for remote. Design of it requires several roundtrips per individual package lookup. It was a quick and dirty hack, and did the job frankly. Integrate solars caching format, the repo just becomes akin to how debian/rpm distros do it- pull down a cache, operate on the cache locally. Fairly fast in my own playing for pkgcore. binary-breakage protection Funnily enough... That one can be done without tree changes too via something we're calling reparenting. There're some vague suggestions of roughly how to do it at [1]. literal re-parenting is a grand way to make collision-protect give you the finger, assuming you intend on integrating collision-protect one of these days. Meanwhile, kudos, portage already has this- FEATURES=preserve-libs. Haven't looked to see if it's been released yet, although it's been around for just over a month so no clue if it's been released yet. Personally hate the feature (revdep-rebuild issues among other things), but it's in. Finally, regarding the weekly portage fud, probably worth noting that despite the claims about portage source being absolute crap, unmodifiable, example above contradicts that bit. Further... * parallelization patches in bugzie * long term co-exinstance of prefix branch * several portage guis * packages.gentoo.org (surprise surprise, it uses portage) all of which are created/maintained by non-portage developers contradicts fair bit of BS regarding portages internals. First two involve pretty heavy mods to the unmodifiable internals, rest are demonstrations of usage of the apis, which surprisingly, isn't that bad. Certainly not how I'd do it given the ability to do a cleanslate, but I prefer a different approach doesn't automatically mean it's shite folks. Part of the usual rant comes down to a long standing meme from pre .51.* days; code back then *was* pretty fricking ugly in spots. I used to call it c code written in python for example- quite a large amount of refactoring since then has changed that. It ain't perfect (base design forced by the legacy API for example is a core reason for pkgcore even existing), but it's certainly not as bad as ciaran paints it. Very least, please take the time to actually dig into the source and form your own opinion, instead of just accepting it as fact because he repeats it damn near daily. ~harring pgpDdoDleOuuf.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 09:49:38 +0200 Thomas Rösner [EMAIL PROTECTED] wrote: A package manager that supports a better binary package format (split out local metadata would be a good start) combined with a third party binary provider could deliver that with no tree changes. But then you'd need a tree of binary packages, which you'd only get with many users of your package manager, which would depend on official Gentoo adoption The sort of people who are likely to go ahead and make a decent binary tree are the sort who don't particularly care whether a package manager is officially supported, so long as it does the job well. I think you know that and that's why you did work on PMS PMS doesn't say anything about binary packages, for one... Hm, perhaps you should let somebody else do the PR for paludis? :-) This has nothing to do with PR. It's to do with whether or not Gentoo has a viable future. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 20:14:58 -0700 (PDT) Alec Warner [EMAIL PROTECTED] wrote: Better than many other package managers isn't exactly a glowing commendation. When you consider the disadvantages associated with a source-based distribution, Gentoo has to do a lot better than that in order to be worthwhile -- and it only takes one package manager to be better to make Gentoo not worth using. The goal should be substantially better than any other package manager... Quoting our Philosophy Page: 'The goal of Gentoo is to strive to create near-ideal tools. Tools that can accommodate the needs of many different users all with divergent goals. Don't you love it when you find a tool that does exactly what you want to do? Doesn't it feel great? Our mission is to give that sensation to as many people as possible.' Ah, you're confusing goals with goals. I am unaware of any other goals currently present within Gentoo. I would imagine people have goals, projects have goals; but gentoo has none other that the one above. Now you can make the point that portage is not a 'near-ideal tool' and I'd agree for a large number of use cases; but at least you'd be making a point against something thats actually a goal for us instead of some made up goal like 'compete against Ubuntu/Fedora'. If Ubuntu or Fedora do the job better then Gentoo has failed in its goal of providing a near-ideal tool... That said; people are working on it. You have been hearing that for years I know; most of that effort honestly became pkgcore (more or less). I'm not about to say 'just give portage more time' because that is a stupid statement to make. However I seriously doubt paludis or pkgcore is ready to take over management for our users. Mm, and I don't think anyone's making that claim (not until Paludis reaches 1.0.0_pre, anyway, which is at least three major releases off...). The claim that is being made is that Gentoo's future depends upon one or both being ready to take over, and that it's not something that can continue being treated as sometime in the distant future. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 02:07:33 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, Mar 29, 2007 at 10:04:57PM +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 22:47:46 +0200 Thomas Rösner [EMAIL PROTECTED] wrote: Other things I want from Gentoo right now depend on factors other than the package manager, too; prebuilt packages A package manager that supports a better binary package format (split out local metadata would be a good start) Not really a huge gain; if you're attempting remote, you're better off with a single file for the entire cache anyways. If you're not doing remote, the few seeks required for xpak aren't killer. *shrug* I was thinking local or fast-access to metadata, remote and potentially slow binaries, personally. There are several viable ways of doing it. From benchmarking, a single file cache tends to end up being slower than multiple files for operations that don't involve inspecting most of the tree. It's not a huge issue, and the difference is tiny in comparison to the way Portage does things currently... binary-breakage protection Funnily enough... That one can be done without tree changes too via something we're calling reparenting. There're some vague suggestions of roughly how to do it at [1]. literal re-parenting is a grand way to make collision-protect give you the finger Well yes, but no-one sane is talking about literal reparenting, because there are far better solutions that're almost as easy to implement. assuming you intend on integrating collision-protect one of these days. Hm? No-one's found it interesting or useful enough to ship it as core with Paludis. It's available as a third party hook for anyone who wants it... Meanwhile, kudos, portage already has this- FEATURES=preserve-libs. Haven't looked to see if it's been released yet, although it's been around for just over a month so no clue if it's been released yet. Personally hate the feature (revdep-rebuild issues among other things), but it's in. We're talking about doing it properly, as you know all too well... Finally, regarding the weekly portage fud, probably worth noting that despite the claims about portage source being absolute crap, unmodifiable, example above contradicts that bit. Further... * parallelization patches in bugzie * long term co-exinstance of prefix branch * several portage guis * packages.gentoo.org (surprise surprise, it uses portage) all of which are created/maintained by non-portage developers contradicts fair bit of BS regarding portages internals. And think what there would be if Portage had a decent API and internals... Part of the usual rant comes down to a long standing meme from pre .51.* days; code back then *was* pretty fricking ugly in spots. I used to call it c code written in python for example- quite a large amount of refactoring since then has changed that. It ain't perfect (base design forced by the legacy API for example is a core reason for pkgcore even existing), but it's certainly not as bad as ciaran paints it. Better than it was is hardly a glowing commendation... I'd use the well known technical description involving polishing here, but someone would just pretend that it's offensive... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 13:55:55 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: If Ubuntu or Fedora do the job better then Gentoo has failed in its goal of providing a near-ideal tool... Semantically speaking, it hasn't failed - there's nothing about providing a better (or nearer-ideal) tool than someone else in that goal statement. :) Kind regards, -- Andrej -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Tuesday 27 March 2007, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? what a lame question ... rather than waste time on this, why dont we get to some relevant issues ... to start with, Paludis will never be an official package manager for Gentoo so long as you are heavily involved. now that we've put a bolt right between the eyes of that pink elephant, how about we address some other things as well ... since you're obviously going to complain about Gentoo's official package manager so long as $pkgmgr != paludis without any intentions of helping address limitations you raise (nor am i expecting you to), why dont you do us all a favor and clamp it. constantly pointing out that $pkgmgr sucks and $pkgmgr does not support xxx and $pkgmgr has this limitation or that stupid design decision and that paludis is the be all end all solution to our problems does not accomplish anything ... it merely serves to piss us all off a good topic for the next council meeting i think would be to start up a spec of requirements that a package manager must satisfy before it'd be an official package manager for Gentoo ... off the top of my head: - the main developers need to be Gentoo developers - source code hosted on Gentoo infrastructure - compatible emerge and ebuild binaries -mike pgpox7YLKJ5fB.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 14:04:15 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 27 March 2007, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? what a lame question ... rather than waste time on this, why dont we get to some relevant issues ... Gentoo's lack of progress is an extremely relevant issue... to start with, Paludis will never be an official package manager for Gentoo so long as you are heavily involved. now that we've put a bolt right between the eyes of that pink elephant, how about we address some other things as well ... Ah, resorting to ad hominem. Is that the best you can manage? Is the best excuse you can provide to users for denying them the things they want and need waah! ciaranm boogeyman!? since you're obviously going to complain about Gentoo's official package manager so long as $pkgmgr != paludis without any intentions of helping address limitations you raise (nor am i expecting you to), why dont you do us all a favor and clamp it. constantly pointing out that $pkgmgr sucks and $pkgmgr does not support xxx and $pkgmgr has this limitation or that stupid design decision and that paludis is the be all end all solution to our problems does not accomplish anything ... it merely serves to piss us all off No no, I'd be quite happy with any package manager that meets my needs and the needs of other people. Portage is not such a package manager, and, let's face it, never will be. The continuing delusion that Portage will somehow magically improve and allow Gentoo to keep up with other distributions is largely why Gentoo is stuck where it is. a good topic for the next council meeting i think would be to start up a spec of requirements that a package manager must satisfy before it'd be an official package manager for Gentoo ... off the top of my head: - the main developers need to be Gentoo developers - source code hosted on Gentoo infrastructure - compatible emerge and ebuild binaries As you know fine well, the Council has already rejected GLEP 49, which says more or less that. As you also know fine well, those requirements mean Gentoo will permanently be stuck with Portage (and when dreaming up silly and biased requirements, bear in mind that Portage was at one point close to being moved off Gentoo infrastructure because of the huge delays in setting up svn...). If you're looking for serious topics to discuss in this area, how about the following? Is Portage severely limiting Gentoo's progress and future direction? What limits need to be removed in the next month, six months and year in order for Gentoo to get closer to its goal of providing 'near-ideal' tools and to regain its competitive edge? What steps can be taken to facilitate this? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 2007-03-30 at 14:04 -0400, Mike Frysinger wrote: On Tuesday 27 March 2007, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? what a lame question ... rather than waste time on this, why dont we get to some relevant issues ... to start with, Paludis will never be an official package manager for Gentoo so long as you are heavily involved. i don't think that personal issues should be taken into account when it comes to choosing a new official package manager for gentoo. Matthias -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 2007-03-30 at 19:35 +0100, Ciaran McCreesh wrote: a good topic for the next council meeting i think would be to start up a spec of requirements that a package manager must satisfy before it'd be an official package manager for Gentoo ... off the top of my head: - the main developers need to be Gentoo developers - source code hosted on Gentoo infrastructure - compatible emerge and ebuild binaries As you know fine well, the Council has already rejected GLEP 49, which says more or less that. As you also know fine well, those requirements mean Gentoo will permanently be stuck with Portage (and when dreaming up silly and biased requirements, bear in mind that Portage was at one point close to being moved off Gentoo infrastructure because of the huge delays in setting up svn...). Wouldn't this be the same as all MTAs providing sendmail compatibility? Whereas existing tools still Just Work? -- Homer Parker [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 13:50:39 -0500 Homer Parker [EMAIL PROTECTED] wrote: Wouldn't this be the same as all MTAs providing sendmail compatibility? Whereas existing tools still Just Work? It depends upon the degree to which one specifies 'sendmail compatibility'. Does it mean shares some of the same commandline options or shares exactly the same configuration file format and all bugs and produces identical output? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 2007-03-30 at 20:42 +0200, Matthias Langer wrote: i don't think that personal issues should be taken into account when it comes to choosing a new official package manager for gentoo. It's relevant in that people have to work with the developers of the package manager. Unlike most other things in the portage tree, the package manager ties very closely to the very definition of the distribution itself. Hence, if people are unable to get along, then by adopting a package manager like that, you inherently adopt the developers of that package manager and all the personnel issues that accompany it. Ideally, however, I agree with you that it should be based on technical merits. The reality is that there are people involved. And people always complicate things. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 18:50:59 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: A few years ago Gentoo had some serious advantages over the competition. These days, Gentoo is at serious risk of being Red Queened by Ubuntu and Fedora. Providing the same thing that was provided two years ago isn't enough. If Portage can't deliver functionality that makes Gentoo competitive with where Ubuntu will be a year from now, Portage has to be replaced. You seem to be under the misapprehension that Portage == Gentoo. Portage is a tool that Gentoo uses, but it does not Gentoo. Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 21:13:18 +0100 Roy Marples [EMAIL PROTECTED] wrote: On Thu, 29 Mar 2007 18:50:59 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: A few years ago Gentoo had some serious advantages over the competition. These days, Gentoo is at serious risk of being Red Queened by Ubuntu and Fedora. Providing the same thing that was provided two years ago isn't enough. If Portage can't deliver functionality that makes Gentoo competitive with where Ubuntu will be a year from now, Portage has to be replaced. You seem to be under the misapprehension that Portage == Gentoo. No no, I'm saying that at present Portage is one of Gentoo's most severe limiting factors. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 2007-03-30 at 19:35 +0100, Ciaran McCreesh wrote: On Fri, 30 Mar 2007 14:04:15 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 27 March 2007, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? what a lame question ... rather than waste time on this, why dont we get to some relevant issues ... Gentoo's lack of progress is an extremely relevant issue... to start with, Paludis will never be an official package manager for Gentoo so long as you are heavily involved. now that we've put a bolt right between the eyes of that pink elephant, how about we address some other things as well ... Ah, resorting to ad hominem. Is that the best you can manage? Is the best excuse you can provide to users for denying them the things they want and need waah! ciaranm boogeyman!? since you're obviously going to complain about Gentoo's official package manager so long as $pkgmgr != paludis without any intentions of helping address limitations you raise (nor am i expecting you to), why dont you do us all a favor and clamp it. constantly pointing out that $pkgmgr sucks and $pkgmgr does not support xxx and $pkgmgr has this limitation or that stupid design decision and that paludis is the be all end all solution to our problems does not accomplish anything ... it merely serves to piss us all off No no, I'd be quite happy with any package manager that meets my needs and the needs of other people. Portage is not such a package manager, and, let's face it, never will be. The continuing delusion that Portage will somehow magically improve and allow Gentoo to keep up with other distributions is largely why Gentoo is stuck where it is. a good topic for the next council meeting i think would be to start up a spec of requirements that a package manager must satisfy before it'd be an official package manager for Gentoo ... off the top of my head: - the main developers need to be Gentoo developers - source code hosted on Gentoo infrastructure - compatible emerge and ebuild binaries As you know fine well, the Council has already rejected GLEP 49, which says more or less that. As you also know fine well, those requirements mean Gentoo will permanently be stuck with Portage (and when dreaming up silly and biased requirements, bear in mind that Portage was at one point close to being moved off Gentoo infrastructure because of the huge delays in setting up svn...). If you're looking for serious topics to discuss in this area, how about the following? Is Portage severely limiting Gentoo's progress and future direction? What limits need to be removed in the next month, six months and year in order for Gentoo to get closer to its goal of providing 'near-ideal' tools and to regain its competitive edge? What steps can be taken to facilitate this? It seems as on topic to say it here as anywhere else. I like Portage. I like it better than the Synaptic Package manager, yum, apt-get and especially rpm. I feel like it delivers more functionality than all of the package managers I just mentioned. It brought me to Gentoo. It drove me away when I got frustrated with it once. But then it brought me back again. I have used them all. Maybe I don't know the other package managers well enough. But what do I know? Larry -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 15:30:31 -0500 Larry Lines [EMAIL PROTECTED] wrote: It seems as on topic to say it here as anywhere else. I like Portage. I like it better than the Synaptic Package manager, yum, apt-get and especially rpm. I feel like it delivers more functionality than all of the package managers I just mentioned. It brought me to Gentoo. It drove me away when I got frustrated with it once. But then it brought me back again. I have used them all. Maybe I don't know the other package managers well enough. But what do I know? Now ask yourself whether there's anything you'd like to see in Portage that it doesn't already have... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
It depends upon the degree to which one specifies 'sendmail compatibility'. Does it mean shares some of the same commandline options or shares exactly the same configuration file format and all bugs and produces identical output? I think Mike mentioned compatiblebinaries. Not sure if he implied identical output, but compatible command line would be nice. I don't think it's a huge obstacle for paludis, though. Love, H -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 22:41:47 +0200 Michael Krelin [EMAIL PROTECTED] wrote: It depends upon the degree to which one specifies 'sendmail compatibility'. Does it mean shares some of the same commandline options or shares exactly the same configuration file format and all bugs and produces identical output? I think Mike mentioned compatiblebinaries. Not sure if he implied identical output, but compatible command line would be nice. I don't think it's a huge obstacle for paludis, though. If it's just an issue of command line, then it's not an issue at all. Even configuration support isn't a major problem (Paludis trunk has highly experimental and highly buggy partial Portage config reading support). The question is whether scripts that, say, parse emerge -pv output have to carry on working. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Friday 30 March 2007, Ciaran McCreesh wrote: Gentoo's lack of progress is an extremely relevant issue... dont push your own agendas under the guise that Gentoo is lacking progress to start with, Paludis will never be an official package manager for Gentoo so long as you are heavily involved. now that we've put a bolt right between the eyes of that pink elephant, how about we address some other things as well ... Ah, resorting to ad hominem. Is that the best you can manage? Is the best excuse you can provide to users for denying them the things they want and need waah! ciaranm boogeyman!? not really, why dont you apply some of your logic: - you are not wanted as an official Gentoo developer ... the past clearly shows this - the official package manager of Gentoo would need to be completely in-house with respect to control, direction, etc... - in-house would require every one who is control of the package manager to be a Gentoo developer - in order for you to gain @gentoo.org again, we'd need either a complete flush of developer blood who would accept you or you to change yourself ... neither of which are realistic so let's put this all together shall we: you are in full control of paludis, you will not be a Gentoo developer, thereforce paludis will not be the official Gentoo package manager No no, I'd be quite happy with any package manager that meets my needs and the needs of other people. Portage is not such a package manager, and, let's face it, never will be. The continuing delusion that Portage will somehow magically improve and allow Gentoo to keep up with other distributions is largely why Gentoo is stuck where it is. there's a magic pill if i ever saw one ... the only available package managers at the moment that satisfy your requirements is paludis ... therefore see previous statements a good topic for the next council meeting i think would be to start up a spec of requirements that a package manager must satisfy before it'd be an official package manager for Gentoo ... off the top of my head: - the main developers need to be Gentoo developers - source code hosted on Gentoo infrastructure - compatible emerge and ebuild binaries As you know fine well, the Council has already rejected GLEP 49, which says more or less that. actually, no, GLEP 49 covers a ton more than what i'm proposing As you also know fine well, those requirements mean Gentoo will permanently be stuck with Portage (and when dreaming up silly and biased requirements, bear in mind that Portage was at one point close to being moved off Gentoo infrastructure because of the huge delays in setting up svn...). again, wrong ... read what i said, my requirements would control selection of an official package manager and in fact are quite general and dont really come with restrictions as you seem to think emerge is a brand name for Gentoo and while you can complain about lack of features all you want, dropping portage and installing a different package manager with a completely different interface will surely causes a huge pita for everyone nowhere did i say the behavior of portage needs to be retained by a package manager ... i was suggesting that any official Gentoo package manager would have a way for users to continue with the general feel of things so that people can do `emerge foo` and know that the package foo would be installed. package managers are free to emulate this however they want and provide whatever other main binary they want. -mike pgpCPg9OdWycp.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Friday 30 March 2007, Seemant Kulleen wrote: On Fri, 2007-03-30 at 20:42 +0200, Matthias Langer wrote: i don't think that personal issues should be taken into account when it comes to choosing a new official package manager for gentoo. It's relevant in that people have to work with the developers of the package manager. Unlike most other things in the portage tree, the package manager ties very closely to the very definition of the distribution itself. Hence, if people are unable to get along, then by adopting a package manager like that, you inherently adopt the developers of that package manager and all the personnel issues that accompany it. Ideally, however, I agree with you that it should be based on technical merits. The reality is that there are people involved. And people always complicate things. thanks seemant, preciously how i'd have put it if i could :) -mike pgp8VVBy8Py5i.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 16:51:54 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 30 March 2007, Ciaran McCreesh wrote: Gentoo's lack of progress is an extremely relevant issue... dont push your own agendas under the guise that Gentoo is lacking progress Don't push your own agenda under the guise that it isn't. - you are not wanted as an official Gentoo developer ... the past clearly shows this Not really... The process by which I became an unofficial Gentoo developer was so flawed that it got replaced as a result... - the official package manager of Gentoo would need to be completely in-house with respect to control, direction, etc... Justify that. What does being in-house have to do with having control? Are you claiming that if the Council asks for a feature to be added to Portage that it will be added, or that if the Council asks for a feature to be added to Paludis that it wouldn't? - in-house would require every one who is control of the package manager to be a Gentoo developer If that were true, you might want to consider the number of Gentoo developers working on each of the three... - in order for you to gain @gentoo.org again, we'd need either a complete flush of developer blood who would accept you or you to change yourself ... neither of which are realistic You're assuming that the majority of developers had anything to do with or cared remotely about any of that. But first and foremost, you missed the part about me *wanting* to gain an @gentoo.org address, which isn't going to happen so long as the disadvantages outweigh whatever gain it's supposed to give... so let's put this all together shall we: you are in full control of paludis, you will not be a Gentoo developer, thereforce paludis will not be the official Gentoo package manager By that logic, Linux can't be the official Gentoo kernel and GCC can't be the official Gentoo compiler, which is clearly silly. No no, I'd be quite happy with any package manager that meets my needs and the needs of other people. Portage is not such a package manager, and, let's face it, never will be. The continuing delusion that Portage will somehow magically improve and allow Gentoo to keep up with other distributions is largely why Gentoo is stuck where it is. there's a magic pill if i ever saw one ... the only available package managers at the moment that satisfy your requirements is paludis ... therefore see previous statements *shrug* That's hardly my fault, is it? As you also know fine well, those requirements mean Gentoo will permanently be stuck with Portage (and when dreaming up silly and biased requirements, bear in mind that Portage was at one point close to being moved off Gentoo infrastructure because of the huge delays in setting up svn...). again, wrong ... read what i said, my requirements would control selection of an official package manager and in fact are quite general and dont really come with restrictions as you seem to think No, it just so happens that they deliberately exclude the only two current viable alternatives to Portage, and experience suggests that it's going to take a substantial amount of time for anyone to come up with a third one... emerge is a brand name for Gentoo and while you can complain about lack of features all you want, dropping portage and installing a different package manager with a completely different interface will surely causes a huge pita for everyone In the same way that dselect is a brand name for Debian? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Saturday 31 March 2007, Ciaran McCreesh wrote: On Fri, 30 Mar 2007 21:13:18 +0100 Roy Marples [EMAIL PROTECTED] wrote: On Thu, 29 Mar 2007 18:50:59 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: A few years ago Gentoo had some serious advantages over the competition. These days, Gentoo is at serious risk of being Red Queened by Ubuntu and Fedora. Providing the same thing that was provided two years ago isn't enough. If Portage can't deliver functionality that makes Gentoo competitive with where Ubuntu will be a year from now, Portage has to be replaced. You seem to be under the misapprehension that Portage == Gentoo. No no, I'm saying that at present Portage is one of Gentoo's most severe limiting factors. In which case your Paludis fork of Gentoo will take off like a scalded cat, and the world will come racing to your door begging for your Mk II version of Gentoo. Go for it, the GPL ensures that you have nothing to lose. Others have done it with varying degrees of success. Kororaa and Sabayon come to mind immediatly, and I seem to remember a very early fork which foundered pretty quickly. I have been using Gentoo for many years, since the 1.2 release anyway. For me, what separates Gentoo from the others is - in order: 1) The ease of updating the file-set and installing new packages. Say what you like against it, Portage does what it was designed to do for the user very effectively. ok the tree breaks occasionally, but to err is human, and I have no difficulty accepting that fact; 2) The superb quality of the documentation. By and large, it's well written and actually understandable, and that's a rarity in this field of endeavour; 3) The IRC channels and the support fora are second to none for getting a quick answer to the current question. Without doubt, while Portage may not equate to Gentoo, it is the single feature which has branded Gentoo as being what it is. -- CS -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 31 Mar 2007 09:13:10 +1200 Christopher Sawtell [EMAIL PROTECTED] wrote: In which case your Paludis fork of Gentoo will take off like a scalded cat, and the world will come racing to your door begging for your Mk II version of Gentoo. Go for it, the GPL ensures that you have nothing to lose. Others have done it with varying degrees of success. Kororaa and Sabayon come to mind immediatly, and I seem to remember a very early fork which foundered pretty quickly. Paludis is a package manager, not a distribution. And no, the GPL does not mean there's nothing to lose -- the Zynot fork did a fair bit of damage to Gentoo, and no-one wants a repeat of that mess... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Am Freitag, 30. März 2007 23:13 schrieb Christopher Sawtell: On Saturday 31 March 2007, Ciaran McCreesh wrote: On Fri, 30 Mar 2007 21:13:18 +0100 Roy Marples [EMAIL PROTECTED] wrote: On Thu, 29 Mar 2007 18:50:59 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: A few years ago Gentoo had some serious advantages over the competition. These days, Gentoo is at serious risk of being Red Queened by Ubuntu and Fedora. Providing the same thing that was provided two years ago isn't enough. If Portage can't deliver functionality that makes Gentoo competitive with where Ubuntu will be a year from now, Portage has to be replaced. You seem to be under the misapprehension that Portage == Gentoo. No no, I'm saying that at present Portage is one of Gentoo's most severe limiting factors. In which case your Paludis fork of Gentoo will take off like a Please, pretty please with sugar atop: Stop this FUD about forking Gentoo. Paludis is not a fork of Gentoo, it's new package manager. The relation between Portage and Paludis can, if at all, probably be compared to dselect vs apt. Don't reply to this mail, just let it drop. Thank you very much. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
It depends upon the degree to which one specifies 'sendmail compatibility'. Does it mean shares some of the same commandline options or shares exactly the same configuration file format and all bugs and produces identical output? I think Mike mentioned compatiblebinaries. Not sure if he implied identical output, but compatible command line would be nice. I don't think it's a huge obstacle for paludis, though. If it's just an issue of command line, then it's not an issue at all. Even configuration support isn't a major problem (Paludis trunk has highly experimental and highly buggy partial Portage config reading support). 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. Love, H -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Anant Narayanan wrote: Hi Mike, On 31-Mar-07, at 2:21 AM, Mike Frysinger wrote: not really, why dont you apply some of your logic: - you are not wanted as an official Gentoo developer ... the past clearly shows this - the official package manager of Gentoo would need to be completely in-house with respect to control, direction, etc... - in-house would require every one who is control of the package manager to be a Gentoo developer - in order for you to gain @gentoo.org again, we'd need either a complete flush of developer blood who would accept you or you to change yourself ... neither of which are realistic so let's put this all together shall we: you are in full control of paludis, you will not be a Gentoo developer, thereforce paludis will not be the official Gentoo package manager The logic is flawed. I don't understand why Gentoo can't switch to paludis so long as there are in-house Gentoo developers ready to maintain and support it. snip emerge is a brand name for Gentoo and while you can complain about lack of features all you want, dropping portage and installing a different package manager with a completely different interface will surely causes a huge pita for everyone It is a rather trivial issue to wrap paludis or pkgcore commands to their emerge equivalents. As discussed before on the thread, mere command-line compatibility is not an issue at all. If a switch is made to a new package, I am sure enough steps will be taken to ensure that the process is as transparent as possible, and most users will not even notice the difference; except of course the immediate benefits. Cheers, -- Anant [EMAIL PROTECTED] mailing list No one is proposing that Gentoo switch to anything at this point. Speaking from a documentation perspective, it's actually more of a task than you'd think. Command wrappers to emerge etc. are one thing, but the output produced is another. Not to mention the fact that Paludis can't do things that Portage does, and vice versa. It's not a 1:1 drop-in replacement, and no one should say it is. There'd be a helluva lot of documentation to rewrite, for both /doc/en/ (which the GDP oversees) as well as the many docs in the various /proj/ spaces. For the forseeable future, since we can't go on vague statements from either camp of feature foo will be ready in, oh, about $x releases, Portage is here to stay. It's not being replaced by anything. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Friday 30 March 2007, Ciaran McCreesh wrote: - you are not wanted as an official Gentoo developer ... the past clearly shows this Not really... The process by which I became an unofficial Gentoo developer was so flawed that it got replaced as a result... sure, the first time ... the second time around, the state of the developer mass was simply too disrupted by your existence - the official package manager of Gentoo would need to be completely in-house with respect to control, direction, etc... Justify that. What does being in-house have to do with having control? Are you claiming that if the Council asks for a feature to be added to Portage that it will be added, or that if the Council asks for a feature to be added to Paludis that it wouldn't? with the package manager in house, none of these things are an issue. we dont have to worry about external developers pulling crap like closing down a repository and thus denying other developers access. allowing the official package manager for Gentoo to be disrupted is not acceptable. You're assuming that the majority of developers had anything to do with or cared remotely about any of that. feel free to maintain whatever delusions you like But first and foremost, you missed the part about me *wanting* to gain an @gentoo.org address, which isn't going to happen so long as the disadvantages outweigh whatever gain it's supposed to give... then you agree it's not going to happen, good so let's put this all together shall we: you are in full control of paludis, you will not be a Gentoo developer, thereforce paludis will not be the official Gentoo package manager By that logic, Linux can't be the official Gentoo kernel and GCC can't be the official Gentoo compiler, which is clearly silly. not the same ... ignoring the fact that there are no real alternatives to these packages, Gentoo is not Linux nor is it GCC ... you can use it in conjunction with other kernels and toolchains No no, I'd be quite happy with any package manager that meets my needs and the needs of other people. Portage is not such a package manager, and, let's face it, never will be. The continuing delusion that Portage will somehow magically improve and allow Gentoo to keep up with other distributions is largely why Gentoo is stuck where it is. there's a magic pill if i ever saw one ... the only available package managers at the moment that satisfy your requirements is paludis ... therefore see previous statements *shrug* That's hardly my fault, is it? it is your fault you wont shut it ... constantly complaining about the faults of other package mangers is not constructive when you dont indend to do anything about it except whine the projects into non-existence No, it just so happens that they deliberately exclude the only two current viable alternatives to Portage, and experience suggests that it's going to take a substantial amount of time for anyone to come up with a third one... you're right, i'm going to go ahead and exclude the ability for anything to become the official powerhouse of Gentoo when it interferes so profoundly with anyone using Gentoo emerge is a brand name for Gentoo and while you can complain about lack of features all you want, dropping portage and installing a different package manager with a completely different interface will surely causes a huge pita for everyone In the same way that dselect is a brand name for Debian? you're confusing dselect with apt-get which is a well-known name aspect of Debian -mike pgpSLXApor5da.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Friday 30 March 2007, Anant Narayanan wrote: The logic is flawed. I don't understand why Gentoo can't switch to paludis so long as there are in-house Gentoo developers ready to maintain and support it. that is your opinion. mine is that the official package manager must be led and maintained in-house. It is a rather trivial issue to wrap paludis or pkgcore commands to their emerge equivalents i never said it wasnt ... all i said is that it must exist -mike pgphrDefzVJyP.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 20:29:46 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: - the official package manager of Gentoo would need to be completely in-house with respect to control, direction, etc... Justify that. What does being in-house have to do with having control? Are you claiming that if the Council asks for a feature to be added to Portage that it will be added, or that if the Council asks for a feature to be added to Paludis that it wouldn't? with the package manager in house, none of these things are an issue. we dont have to worry about external developers pulling crap like closing down a repository and thus denying other developers access. Instead, you have to worry about Gentoo infra people pulling commit access under the guise of 'security measures' and refusing devrel requests to restore it. But you're not addressing the issue. If the Council requests a new feature in Portage, will it happen? By that logic, Linux can't be the official Gentoo kernel and GCC can't be the official Gentoo compiler, which is clearly silly. not the same ... ignoring the fact that there are no real alternatives to these packages, Gentoo is not Linux nor is it GCC ... you can use it in conjunction with other kernels and toolchains and other package managers, as plenty of people will tell you. it is your fault you wont shut it ... constantly complaining about the faults of other package mangers is not constructive when you dont indend to do anything about it except whine the projects into non-existence Except I've done a lot more about it than that... I've gone off and written something that's pretty close to being a replacement. emerge is a brand name for Gentoo and while you can complain about lack of features all you want, dropping portage and installing a different package manager with a completely different interface will surely causes a huge pita for everyone In the same way that dselect is a brand name for Debian? you're confusing dselect with apt-get which is a well-known name aspect of Debian Not at all. dselect used to be a flagship Debian application in the same way that Portage is for Gentoo. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Friday 30 March 2007, Ciaran McCreesh wrote: Instead, you have to worry about Gentoo infra people pulling commit access under the guise of 'security measures' and refusing devrel requests to restore it. agreed, that was complete bs ... it has since been rectified But you're not addressing the issue. If the Council requests a new feature in Portage, will it happen? if the Council felt the need to force something in, then yes, it would happen and other package managers, as plenty of people will tell you. i'm perfectly happy keeping the tree open to alternative package managers ... i'm not perfectly happy releasing control of the main package manager, whichever that may be in the future emerge is a brand name for Gentoo and while you can complain about lack of features all you want, dropping portage and installing a different package manager with a completely different interface will surely causes a huge pita for everyone In the same way that dselect is a brand name for Debian? you're confusing dselect with apt-get which is a well-known name aspect of Debian Not at all. dselect used to be a flagship Debian application in the same way that Portage is for Gentoo. predates my Linux experience ... i'd note however that apt is fully in-house with Debian -mike pgpU4Uy7rwDHk.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 30 Mar 2007 21:03:14 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: But you're not addressing the issue. If the Council requests a new feature in Portage, will it happen? if the Council felt the need to force something in, then yes, it would happen For how many more years do we have to wait for that to happen then? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 2007-03-30 at 22:22 +0100, Ciaran McCreesh wrote: Paludis is a package manager, not a distribution. And no, the GPL does not mean there's nothing to lose -- the Zynot fork did a fair bit of damage to Gentoo, and no-one wants a repeat of that mess... Only in terms of morale. In fact, they did a good thing for Gentoo by purging quite a few poisonous people from it. They didn't break the portage tree or API or ABI or anything in Gentoo. So, I think Christopher is correct in his assertions. Thanks, Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 2007-03-30 at 23:41 +0200, Danny van Dyk wrote: In which case your Paludis fork of Gentoo will take off like a Please, pretty please with sugar atop: Stop this FUD about forking Gentoo. Paludis is not a fork of Gentoo, it's new package manager. The relation between Portage and Paludis can, if at all, probably be compared to dselect vs apt. Actually, I think we're reading him differently, Danny. I read Christopher's email as saying base a fork of Gentoo, using Paludis as its package manager, and run with it. To me, he did not imply that paludis is a fork of gentoo at all. Don't reply to this mail, just let it drop. Thank you very much. Sorry to disobey, but I think it's better to make the communication gap smaller, and dispel the misunderstandings. Thanks, Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Saturday 31 March 2007, Seemant Kulleen wrote: On Fri, 2007-03-30 at 23:41 +0200, Danny van Dyk wrote: In which case your Paludis fork of Gentoo will take off like a Please, pretty please with sugar atop: Stop this FUD about forking Gentoo. Paludis is not a fork of Gentoo, it's new package manager. The relation between Portage and Paludis can, if at all, probably be compared to dselect vs apt. Actually, I think we're reading him differently, Danny. I read Christopher's email as saying base a fork of Gentoo, using Paludis as its package manager, and run with it. To me, he did not imply that paludis is a fork of gentoo at all. Correct, because the only way Ciaran can prove beyond doubt that his Paludis is a viable option is to see hundreds, nay millions, of people using it. I'm quite sure that he won't achieve that goal by bleating in here as frequently as he is currently. -- CS -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 2007-03-31 at 14:53 +1200, Christopher Sawtell wrote: Correct, because the only way Ciaran can prove beyond doubt that his Paludis is a viable option is to see hundreds, nay millions, of people using it. I'm quite sure that he won't achieve that goal by bleating in here as frequently as he is currently. That's uncalled for. There's no need to get nasty. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [soc] Python bindings for Paludis
Hi, On Fri, 30 Mar 2007 15:28:52 -0400 Seemant Kulleen [EMAIL PROTECTED] wrote: On Fri, 2007-03-30 at 20:42 +0200, Matthias Langer wrote: i don't think that personal issues should be taken into account when it comes to choosing a new official package manager for gentoo. It's relevant in that people have to work with the developers of the package manager. Unlike most other things in the portage tree, the package manager ties very closely to the very definition of the distribution itself. Hence, if people are unable to get along, then by adopting a package manager like that, you inherently adopt the developers of that package manager and all the personnel issues that accompany it. Ideally, however, I agree with you that it should be based on technical merits. The reality is that there are people involved. And people always complicate things. Isn't it true that people are meant to solve/facilitate things, not to make them harder/more complicate ? Rumen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: On 28-Mar-07, at 1:45 AM, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On 29-Mar-07, at 2:26 PM, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Both portage and the tree. I don't deny the fact that portage isn't the best way of using the tree but it's a lot better than many of the package managers (think other distros) out there. In fact, I've hardly felt as if portage was limiting me in any way for the past 2 years or so. It just works, and that's a good thing (TM). Alternative package managers are also good for Gentoo as a whole, but I don't think replacing portage should be our top priority. We officially support portage, and will do so for quite some time to come. Cheers, -- Anant -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 22:46:14 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: On 29-Mar-07, at 2:26 PM, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Both portage and the tree. I don't deny the fact that portage isn't the best way of using the tree but it's a lot better than many of the package managers (think other distros) out there. Better than many other package managers isn't exactly a glowing commendation. When you consider the disadvantages associated with a source-based distribution, Gentoo has to do a lot better than that in order to be worthwhile -- and it only takes one package manager to be better to make Gentoo not worth using. The goal should be substantially better than any other package manager... In fact, I've hardly felt as if portage was limiting me in any way for the past 2 years or so. It just works, and that's a good thing (TM). Have a look at [1] and all the open Portage should... bugs. Would any of those improve the user experience for you? Can you think of other features of a similar nature that would make your life easier? That Portage works does not mean that it is anywhere near ideal... A few years ago Gentoo had some serious advantages over the competition. These days, Gentoo is at serious risk of being Red Queened by Ubuntu and Fedora. Providing the same thing that was provided two years ago isn't enough. If Portage can't deliver functionality that makes Gentoo competitive with where Ubuntu will be a year from now, Portage has to be replaced. [1]: http://ciaranm.org/show_post/95 -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 09:56 +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: On 28-Mar-07, at 1:45 AM, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Can you please stop taking cheap pot shots every chance you get. We all get it. You are not a fan of portage. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 11:57:36 -0700 Ned Ludd [EMAIL PROTECTED] wrote: Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Can you please stop taking cheap pot shots every chance you get. We all get it. You are not a fan of portage. And that attitude is exactly why Gentoo is no better off than it was two years ago. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 20:06 +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 11:57:36 -0700 Ned Ludd [EMAIL PROTECTED] wrote: Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Can you please stop taking cheap pot shots every chance you get. We all get it. You are not a fan of portage. And that attitude is exactly why Gentoo is no better off than it was two years ago. You are being dismissive of the hard work others are doing. I find that downright offensive. You want to write a kickass package manager then by all means do it. But trying to make yourself look good by making others look bad is an underhanded trick. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 12:25:00 -0700 Ned Ludd [EMAIL PROTECTED] wrote: You are being dismissive of the hard work others are doing. I find that downright offensive. You want to write a kickass package manager then by all means do it. But trying to make yourself look good by making others look bad is an underhanded trick. This has nothing to do with the people. It's about the code. Not being able to make changes to a huge mess of spaghetti code doesn't imply any lack of talent in those who try... Please stop looking for excuses for interpreting something as offensive... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 21:02 +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 12:25:00 -0700 Ned Ludd [EMAIL PROTECTED] wrote: You are being dismissive of the hard work others are doing. I find that downright offensive. You want to write a kickass package manager then by all means do it. But trying to make yourself look good by making others look bad is an underhanded trick. This has nothing to do with the people. It's about the code. Not being able to make changes to a huge mess of spaghetti code doesn't imply any lack of talent in those who try... Please stop looking for excuses for interpreting something as offensive... The correct reply should of been. I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Hi, Ciaran McCreesh wrote: Have a look at [1] and all the open Portage should... bugs. Would any of those improve the user experience for you? Can you think of other features of a similar nature that would make your life easier? Funny thing is: the only thing that I'd really care about are the USE deps. But to actually get those, it's not enough to use paludis, you'd have to have an ebuild tree that actually provides them. Then you'd get things like sane split up of monolith upstream packages, a way to implement multilib without binary packages, and other things I can't think of right now. Other things I want from Gentoo right now depend on factors other than the package manager, too; prebuilt packages, slow-moving tree, binary-breakage protection (and pre-upgrade notices of major changes). If you could cast a spell that got those features in, I'd happily wait 30 minutes for emerge -Duvat world... So to have an incentive to switch to paludis, it would have to be a supported Gentoo package manager, which drives what devs put into the tree. And to get there, it would have to get the masses to switch to paludis... So I think to get anywhere with all of this is to figure out ways to add the features to the tree without breaking portage (for the use flag dep example: let portage die on not matched use flag deps just like it does now in pkg_setup for the manual use flag checks; real support would of course mean reemerging the package in question with the right flags). And then, if portage really can't keep up with the pace of changes, alternatives would *have* to be considered. Am I making sense? That Portage works does not mean that it is anywhere near ideal... Nothing ever will be. :) Regards, Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 13:33:31 -0700 Ned Ludd [EMAIL PROTECTED] wrote: The correct reply should of been. I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots That would have been a possible response. Another reasonable response would have been the one that he made, clarifying his original statement in case someone took offence where none was meant. If one reads the mails in a spirit of giving someone the benefit of the doubt rather than automatically thinking the worst, there's no reason this subthread needed to exist. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ned Ludd wrote: The correct reply should of been. I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots Man, stop playing the silly Ooh, we are all so fragile and offendable game. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 22:47:46 +0200 Thomas Rösner [EMAIL PROTECTED] wrote: Other things I want from Gentoo right now depend on factors other than the package manager, too; prebuilt packages A package manager that supports a better binary package format (split out local metadata would be a good start) combined with a third party binary provider could deliver that with no tree changes. Heck, it's even doable with Portage's binaries, although according to a Gentoo-based distribution that tried it, your 30 minutes would be optimistic for -uDpv world... binary-breakage protection Funnily enough... That one can be done without tree changes too via something we're calling reparenting. There're some vague suggestions of roughly how to do it at [1]. That Portage works does not mean that it is anywhere near ideal... Nothing ever will be. :) Probably not, but they could be a lot closer to it. [1]: http://paludis.pioto.org/trac/ticket/129 -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On 29-Mar-07, at 11:20 PM, Ciaran McCreesh wrote: Have a look at [1] and all the open Portage should... bugs. Would any of those improve the user experience for you? Can you think of other features of a similar nature that would make your life easier? That Portage works does not mean that it is anywhere near ideal... Sure it's not ideal and I acknowledge that. But portage is tied very closely to Gentoo for historical reasons, and it is not reasonable to expect an alternate package manager to replace it (not in the near future atleast). How about implementing the features you mention in portage? I know what your response would be though: portage is too much spaghetti code to even think about it. But guess what, if you do succeed in making a patch that adds a feature to portage, it'll be accepted faster than you think. Maybe, given the current situation, that is the best way to provide a better experience to the users you are so worried about; atleast for those users who don't want to try out package managers unsupported by Gentoo. A few years ago Gentoo had some serious advantages over the competition. These days, Gentoo is at serious risk of being Red Queened by Ubuntu and Fedora. Providing the same thing that was provided two years ago isn't enough. If Portage can't deliver functionality that makes Gentoo competitive with where Ubuntu will be a year from now, Portage has to be replaced. You are comparing Gentoo with the wrong distributions. Both Ubuntu and Fedora have people working on it 24x7, and they are being *paid* to do so. Gentoo is a community distribution which is entirely volunteer driven, and you can't expect it to match with the pace of commercial distributions such as the ones you mention. Debian is a distro you could compare with, and you'll have to accept the fact that they develop *for* the developers, much like Gentoo. So, really, I don't care if Ubuntu becomes more popular than Gentoo. Isn't it already?! Point is, the day when more than 50% of the devs feel we need a new package manager, will be the day a replacement will be made. Cheers, -- Anant -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 14:03 -0700, Ilya A. Volynets-Evenbakh wrote: Ned Ludd wrote: The correct reply should of been. I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots Man, stop playing the silly Ooh, we are all so fragile and offendable game. Worry about yourself please. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 2007-03-30 at 03:07 +0530, Anant Narayanan wrote: Sure it's not ideal and I acknowledge that. But portage is tied very closely to Gentoo for historical reasons, and it is not reasonable to expect an alternate package manager to replace it (not in the near future atleast). Historical reasons aren't necessarily the correct reasons. I'd almost say that your sentence has officially heralded the age of Debianisation. How about implementing the features you mention in portage? I know what your response would be though: portage is too much spaghetti code to even think about it. Have you ever tried to add features to a frankenstein of a beast? What is the value to you in doing something like that? Isn't there more value in designing something based on what you've learned instead? We can all go all day about this and not convince each other, so please let's just drop this line of thinking. But guess what, if you do succeed in making a patch that adds a feature to portage, it'll be accepted faster than you think. Maybe, given the current situation, that is the best way to provide a better experience to the users you are so worried about; atleast for those users who don't want to try out package managers unsupported by Gentoo. What are you basing any of this on? Sounds like speculation that doesn't help anything. You are comparing Gentoo with the wrong distributions. Both Ubuntu and Fedora have people working on it 24x7, and they are being *paid* to do so. Gentoo is a community distribution which is entirely volunteer driven, and you can't expect it to match with the pace of commercial distributions such as the ones you mention. Debian is a distro you could compare with, and you'll have to accept the fact that they develop *for* the developers, much like Gentoo. Debian was never a distro that I thought we'd emulate, or should emulate. Turns out I was wrong, I suppose. So, really, I don't care if Ubuntu becomes more popular than Gentoo. Isn't it already?! Here we agree. I don't think Ciaran is arguing popularity either. He's arguing that the compelling case for using Gentoo is what's fading. There's a difference. Point is, the day when more than 50% of the devs feel we need a new package manager, will be the day a replacement will be made. I'm not entirely sure on your reasons for this statement. If developers' don't face any API changes, why should we have to have a political vote on which package manager gets dubbed the one true official one? Why should it be a popularity contest? Why can it not be a technical superiority issue? If there is a compelling set of technical reasons to replace portage, why ignore that set? Portage is more than the package manager. Its life comes from the portage _tree_. Portage is just the tool that is used to use that tree. If that tool is outdated (and let's be honest, it kind of is), then switching it is not actually a bad thing. In sum, I'm not sure I like this direction of basing technical things on political decisions. Thanks, Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 22:46:14 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: On 29-Mar-07, at 2:26 PM, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Both portage and the tree. I don't deny the fact that portage isn't the best way of using the tree but it's a lot better than many of the package managers (think other distros) out there. Better than many other package managers isn't exactly a glowing commendation. When you consider the disadvantages associated with a source-based distribution, Gentoo has to do a lot better than that in order to be worthwhile -- and it only takes one package manager to be better to make Gentoo not worth using. The goal should be substantially better than any other package manager... Quoting our Philosophy Page: 'The goal of Gentoo is to strive to create near-ideal tools. Tools that can accommodate the needs of many different users all with divergent goals. Don't you love it when you find a tool that does exactly what you want to do? Doesn't it feel great? Our mission is to give that sensation to as many people as possible.' I am unaware of any other goals currently present within Gentoo. I would imagine people have goals, projects have goals; but gentoo has none other that the one above. Now you can make the point that portage is not a 'near-ideal tool' and I'd agree for a large number of use cases; but at least you'd be making a point against something thats actually a goal for us instead of some made up goal like 'compete against Ubuntu/Fedora'. That said; people are working on it. You have been hearing that for years I know; most of that effort honestly became pkgcore (more or less). I'm not about to say 'just give portage more time' because that is a stupid statement to make. However I seriously doubt paludis or pkgcore is ready to take over management for our users. For being a badly designed application, portage has a large pair of shoes to fill. -Alec -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
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
Re: [gentoo-dev] [soc] Python bindings for Paludis
snip 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. I find the reasoning to be quite justified. 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 look forward to using a better package manager then :) Cheers, -- Anant -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seemant Kulleen wrote: 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. True, and the underpinnings are not the only reason to switch. Should be also the user experience (speed, features) and that can be evaluated by every dev, or even users - it's what matters most for them, isn't it. Of course internal design is important for maintainability etc, but it's not all. 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? Yeah, I don't think it's now helpful to hear that portage sux and paludis can do $x and $y and $z, over and over again. Someone's little too early for an election campaign? - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDKyhtbrAj05h3oQRAireAJ9c/9J0opR6X+IKKkQQHZHbqvO5wACfbjPn 97vZFLm5eFsdW23AHGW04uM= =WEo/ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Tuesday 27 March 2007, Ciaran McCreesh wrote: On Tue, 27 Mar 2007 15:19:29 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: one of Gentoo's priorities is to enable alternative package managers to coexist sanely ... it is not one of Gentoo's priorities at this time to replace Portage with a different package manager Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? If it is not a limiting factor, portage is certainly a critical part of the distribution. And yes there are many features that should be offered but are not. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpHbA1mbup1V.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Hi Ciaran, On 28-Mar-07, at 1:45 AM, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Of course that doesn't mean that it doesn't have its drawbacks, certainly things can be done in better ways; but isn't that the case with all legacy software? Cheers, -- Anant -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sunday 25 March 2007, Michael Krelin wrote: the werent the same question nor were they the same answer They weren't the same, but the second answer was definitely wrong: So is alternative package manager support something that's considered important and a priority by the Council? yes Did you not say that finding alternatives to Portage is one of Gentoo's priorities? no i did not, nor does that apply here because it explicitly states that you *did not* say it (and the wording doesn't differ enough to justify it), not only that it doesn't apply. i think the use of negatives has confused you ... the answers i posted to ciaranm's questions in both cases are correct one of Gentoo's priorities is to enable alternative package managers to coexist sanely ... it is not one of Gentoo's priorities at this time to replace Portage with a different package manager -mike pgp4b468sFSLB.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Tue, 27 Mar 2007 15:19:29 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: one of Gentoo's priorities is to enable alternative package managers to coexist sanely ... it is not one of Gentoo's priorities at this time to replace Portage with a different package manager Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
the werent the same question nor were they the same answer They weren't the same, but the second answer was definitely wrong: So is alternative package manager support something that's considered important and a priority by the Council? yes Did you not say that finding alternatives to Portage is one of Gentoo's priorities? no i did not, nor does that apply here because it explicitly states that you *did not* say it (and the wording doesn't differ enough to justify it), not only that it doesn't apply. i think the use of negatives has confused you ... the answers i posted to ciaranm's questions in both cases are correct one of Gentoo's priorities is to enable alternative package managers to coexist sanely ... it is not one of Gentoo's priorities at this time to replace Portage with a different package manager I don't think either question implied replacing portage, but nevermind. As, I believe, I mentioned once, it's nothing but a hairsplitting. You made yourself clear enough. Love, H -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Saturday 24 March 2007, Matthias Langer wrote: In my opinion, any project that has reasonable potential to improve Gentoo as a whole which doesnt apply here -mike pgpkZMxj5OVdW.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sun, 25 Mar 2007 10:40:51 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Saturday 24 March 2007, Matthias Langer wrote: In my opinion, any project that has reasonable potential to improve Gentoo as a whole which doesnt apply here Did you not say that finding alternatives to Portage is one of Gentoo's priorities? -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sunday 25 March 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Saturday 24 March 2007, Matthias Langer wrote: In my opinion, any project that has reasonable potential to improve Gentoo as a whole which doesnt apply here Did you not say that finding alternatives to Portage is one of Gentoo's priorities? no i did not, nor does that apply here the idea that Python bindings for Paludis improves Gentoo as a whole is laughable and completely irrelevant to the topic of PMS -mike pgp2vOwgYkjnT.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sunday 25 of March 2007 16:58:10 Mike Frysinger wrote: Did you not say that finding alternatives to Portage is one of Gentoo's priorities? no i did not, nor does that apply here not to put anything in your mouth, but I am a little confused: http://article.gmane.org/gmane.linux.gentoo.devel/46648 -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Piotr Jaroszyński wrote: On Sunday 25 of March 2007 16:58:10 Mike Frysinger wrote: Did you not say that finding alternatives to Portage is one of Gentoo's priorities? no i did not, nor does that apply here not to put anything in your mouth, but I am a little confused: http://article.gmane.org/gmane.linux.gentoo.devel/46648 Support for an alternative package manager != language bindings for said package manager :P -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sunday 25 of March 2007 17:54:24 Andrew Gaffney wrote: Support for an alternative package manager != language bindings for said package manager :P heh, I just wanted a clarification of the Council standpoint in the matter of finding alternatives to portage, which became quite vague after reading two contrary answers to the same question. Anyway tbh I hoped to get some technical comments, but it seems most of the people haven't even read my application :/ At least no one is saying it would hurt Gentoo, which makes me partly happy. P.S. maybe we should start gathering project ideas for the next year already to not look so miserable in comparison with other orgs? -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sunday 25 March 2007, Piotr Jaroszyński wrote: On Sunday 25 of March 2007 17:54:24 Andrew Gaffney wrote: Support for an alternative package manager != language bindings for said package manager :P heh, I just wanted a clarification of the Council standpoint in the matter of finding alternatives to portage, which became quite vague after reading two contrary answers to the same question. the werent the same question nor were they the same answer -mike pgp35U6tQPqhf.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
the werent the same question nor were they the same answer They weren't the same, but the second answer was definitely wrong: So is alternative package manager support something that's considered important and a priority by the Council? yes Did you not say that finding alternatives to Portage is one of Gentoo's priorities? no i did not, nor does that apply here because it explicitly states that you *did not* say it (and the wording doesn't differ enough to justify it), not only that it doesn't apply. The latter circumstance, though, renders the whole dispute useless pedantry. Love, H -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Piotr Jaroszyński wrote: Hello, I have already submitted my application, but want to advertise it over here too :] Comments are welcome! Summary: Create Python bindings, associated documentation and test cases for the Paludis public API, and allow subclassing of Paludis classes using Python. Check my counterproposal. I know it is more broad but it also fits better Gentoo as whole. For the ones that aren't following gentoo-soc: - C/C++/Ruby/python bindings/API for package managers. The idea is to have some kind of common ground for applications willing to use our wonderful package managers. Task list: - define a basic API for basic query and basic commands - implement it for paludis/pkgcore/portage a non native language - implement a little front-end using it (that would act as a subset of emerge) - extend the API to cover more features. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, Mar 24, 2007 at 01:46:45PM +1100, Jonathan Adamczewski wrote: Paludis is a tool used for working with the Gentoo Portage tree - there is no problem with it being part of a Gentoo Google Summer of Code project as it will benefit the Gentoo project and its users. Why not simply solve the situation by making paludis the mentoring organisation instead of Gentoo? cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpPRc9PWndC4.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, Mar 24, 2007 at 01:46:45PM +1100, Jonathan Adamczewski wrote: Paludis is a tool used for working with the Gentoo Portage tree - there is no problem with it being part of a Gentoo Google Summer of Code project as it will benefit the Gentoo project and its users. Why not simply solve the situation by making paludis the mentoring organisation instead of Gentoo? You assume that the paludis folks applied for mentoring org status and were accepted; which didn't happen. The Gentoo SoC team is aware of lingering issues regarding projects like pkgcore and paludis and whatnot. I'd prefer we rank applications (and applicants) based on the merits of their application as opposed to some arbitrary political system. If it happens that someone submits a very well thought out idea with defined goals, milestones, has a design plan and seems to have decent merit but happens to be say, a paludis related project; well I guess the other people should have submitted better proposals. In the end most of the ranking and chosing of projects is a huge judgement call by the SoC team and the mentors each year anyway. Personally I think python bindings for paludis push the boundaries of 'does this project affect gentoo' while say, the project idea for 'adding an ebuild development tool for paludis' does not push the boundaries. One is only tangentially related (paludis happens to be a tool that uses ebuilds) and the other could be more of a cross-project project, with 1 gentoo mentor and 1 paludis mentor. However my opinon (and most of this ensuing discussion) is probably better served for when applications are actually ranked. So in closing, we know, some of us don't care, we will disuss it during ranking. -Alec -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, Mar 24, 2007 at 01:31:08AM -0700, Alec Warner wrote: [some stuff] Thanks for the explanation, i guess that makes sense. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgp0iYPX1u5mI.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We should not have third-party projects be part of SOC -- specifically, things that are not Gentoo projects. I'd lobby this whether it was pkgcore or paludis being proposed, so don't bother trying to pin partisan accusations. Point is, it's not a Gentoo project. PMS, portage tests, or doing a gentoo.org rewrite -- those are Gentoo projects by any reasonable standards, I should think. Not entirely true. The very reason Google selects Linux Distributions as mentoring organizations is because a lot of projects that benefit the entire FOSS community in general are mentored by them. Have a look at the project ideas for Debian or Fedora; they have several ideas that have nothing to do with the distro, but do benefit a broader audience. I see nothing wrong in mentoring projects that are not related to Gentoo in any way at all, leave alone projects like Paludis which have provide *direct* benefits for (some) Gentoo users. I completely agree with what Alec says, applications must be ranked purely on the basis of their technical merit, rather than evaluating how it helps a specific subset of projects. Cheers, - -- Anant -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGBRM9Ton3xA72kU4RAh5VAJ9/1DCzWqm5zMFyIPW6MccQEq1akQCgjOGk 0eiZGjA3Jw/ztUTuwTE/HQk= =Zr/4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, Mar 24, 2007 at 01:50:19AM -0400, Mike Frysinger wrote: On Friday 23 March 2007, Josh Saddler wrote: I'm very strongly against using Gentoo SoC time and resources for things that are not officially part of Gentoo (yes, this statement could be spun however you wish) or are not official Gentoo projects. And no, just because a project has Gentoo developers in it doesn't mean that it's a Gentoo project -- let's avoid the gray areas now, shall we? Just because we have Gentoo devs who are also Gnome upstream doesn't make their Gnome-related packages that happen to be in our tree official Gentoo projects. i'd have to agree here -mike Ditto. Gentoo SoC projects need to be for Gentoo developed and sponsored code/projects, not third party projects, no matter how much they would whither and die without a gentoo core. There was an example of gentoo+gnome integration (i think) in a previous email - that wouldn't be any more appropriate. Unless there's the Gentoo Inc copyright in the header, it isn't eligible in my opinion. ~mcummings, the other mike -- -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E -o()o-- Hi, I'm a .signature virus! Please copy me in your ~/.signature. pgpaXhlsVZ3GD.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Saturday 24 of March 2007 13:54:51 Michael Cummings wrote: Ditto. Gentoo SoC projects need to be for Gentoo developed and sponsored code/projects, not third party projects, no matter how much they would whither and die without a gentoo core. There was an example of gentoo+gnome integration (i think) in a previous email - that wouldn't be any more appropriate. Unless there's the Gentoo Inc copyright in the header, it isn't eligible in my opinion. Anant really meant his mail: https://wiki.ubuntu.com/GoogleSoC2007 - Revision-controlled home directories - we have the same idea for /etc - Python Basics Training Program - Math System for Children - Educational Apps - Tool for computer aided vocabulary learning - Gnome Media Center - G-Playah ... Also Google FAQ is worth reading: http://code.google.com/support/bin/answer.py?answer=60291 Google seems to concern more about the FOSS community than the organizations' copyright in the header and imho that's a good thing. Gentoo is supposed to be a _mentoring_ organization, so the only question is whether Gentoo mentors are capable of mentoring a project or not. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Michael Cummings wrote: [Sat Mar 24 2007, 07:54:51AM CDT] On Sat, Mar 24, 2007 at 01:50:19AM -0400, Mike Frysinger wrote: On Friday 23 March 2007, Josh Saddler wrote: I'm very strongly against using Gentoo SoC time and resources for things that are not officially part of Gentoo (yes, this statement could be spun however you wish) or are not official Gentoo projects. And no, just because a project has Gentoo developers in it doesn't mean that it's a Gentoo project -- let's avoid the gray areas now, shall we? Just because we have Gentoo devs who are also Gnome upstream doesn't make their Gnome-related packages that happen to be in our tree official Gentoo projects. i'd have to agree here -mike Ditto. Gentoo SoC projects need to be for Gentoo developed and sponsored code/projects, not third party projects, no matter how much they would whither and die without a gentoo core. There was an example of gentoo+gnome integration (i think) in a previous email - that wouldn't be any more appropriate. Unless there's the Gentoo Inc copyright in the header, it isn't eligible in my opinion. Okay, let me explain why I think all three of you have the wrong idea here, although I have sympathy for your argument. First, there's the issue that hosting projects that are only tangentially related to Gentoo drains our resources. To some extent that's true, but it's a minimal effect. What resources are we talking about? Infra provides cvs or svn for the SOC students, we have a gentoo-soc mailing list, and I suspect there will be a gentoo-soc planet again. Getting that set up requires significant effort, but the difference in effort between 5 students and 10 students is not very much. (One could imagine web-based projects that would also require Infra to provide various web-based or network-based apps, but those are likely to be for true Gentoo projects, so I'm discounting those for this discussion.) Gentoo also provides mentors, who choose to volunteer their time. If nobody wants to mentor a project, it's not going to be accepted. You could argue that by allowing these sorts of projects we are encouraging devs to spend time on non-Gentoo stuff. *Shrug* Our devs are volunteers, so I figure they're going to spend their time doing what they want to do anyway. (Incidentally, if that gnome+gentoo student chose to submit his or her proposal to Gnome, nothing would stop one of our devs from officially mentoring that person as long as the Gnome folks agreed (or unofficially mentoring if they didn't). Of course, for many my above argument is beside the point. It isn't the resources, it's the principle of the thing. SOC projects hosted by Gentoo should be Gentoo projects that clearly benefit Gentoo and have (c) Gentoo Foundation, Inc stamped on them. I have sympathy for that argument, but I respectfully disagree, because I think that argument misses the essential point of Google's Summer of Code program. The primary goal is to get students involved in developing open source code, and thus bringing new blood into the community. Even if our students don't become Gentoo developers, if they have a good experience they are likely to be friendly to open-source software, at least, and perhaps even long-term active contributors. My view is that we are providing an altruistic service here to benefit the community in which we reside, not to get free labor and a bit of cash (Google pays the hosting organizations as well as the students). (That said, we nonetheless did pick up some nice code and at least two devs from last year's program. Also, our being chosen to participate nicely enhances our reputation, both as being a significant player in open-source and as being one of the good guys in the community.) It's possible that I'm not being terribly convincing. After all, a student who submits a proposal to nmap is almost certainly going to be working on nmap, not, say, honeynets. Why should Gentoo be different? Well, for one thing, our main product is a distribution, and we spend most of our time integrating existing code instead of writing new code, so we're pretty much a natural umbrella organization anyway. Last year one of the proposals that was submitted to a number of distributions (including ours) involved porting Sun's ZFS to Linux. It was a very well-written proposal, and it was accepted by several different organizations. (I don't remember which organization he went with, but it wasn't Gentoo.) Clearly having ZFS support in Linux would benefit Gentoo in the long run, even if it wasn't an obvious Gentoo project, and I'd have been perfectly happy supporting it. (In case you're curious, you can follow along the progress of that proposal at http://zfs-on-fuse.blogspot.com/, and he just released the first beta at the beginning of this month.) Finally, let me be more specific about pkgcore- or paludis- or gnome+gentoo-related proposals. If not us as a mentoring org,
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 24 Mar 2007 08:09:09 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Check my counterproposal. I know it is more broad but it also fits better Gentoo as whole. For the ones that aren't following gentoo-soc: - C/C++/Ruby/python bindings/API for package managers. The idea is to have some kind of common ground for applications willing to use our wonderful package managers. Which is all very nice in theory, but completely impractical and useless in practice. There's far too much difference and far too much complexity implementation-wise to make this practical for any non-trivial functionality. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ah, a couple additional things. Diego wrote me and commented that he's not a big fan of accepting proposals from existing devs, since the goal of the program is to get _new_ blood into open-source projects. I think that's a good point, and my personal preference is to accept strong proposals from new folks. That said, I'd rather we accept strong proposals from eligible existing devs than lousy proposals from the new folks, if that should turn out to be a choice we have to make. *Shrug* Also, it may not have been clear from my previous post that if we get inundated by strong, obviously-Gentoo-specific proposals, I suspect they'll push the less-Gentoo-specific proposals right off the acceptance list, unless those alternative proposals are amazingly impressive. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpLPhE6K4meX.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Grant Goodyear wrote: [snip] PS. So, anybody have any actual technical comments about this proposal? Yes. pioto's proposal is weak. lu_zero's counterproposal for developing a method of having a package manager agnostic API is much more useful than developing one language binding for one package manager. Assuming you mean piotr, who is not pioto... The difference is, piotr's proposal is possible and doable within the timeframe, whereas lu_zero's sounds nice if you don't know anything about any of the package managers in question and can't be delivered within three months. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Saturday 24 of March 2007 17:30:55 Mike Doty wrote: Yes. pioto's proposal is weak. lu_zero's counterproposal for developing a method of having a package manager agnostic API is much more useful than developing one language binding for one package manager. 1. pioto is a mentor this year... ;] 2. hardly technical issue 3. see ciaran's post -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Yes. pioto's proposal is weak. You mean Piotr, right? He's a different person from me. -- Mike Kelly -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ciaran McCreesh wrote: [Sat Mar 24 2007, 11:38:45AM CDT] On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Grant Goodyear wrote: [snip] PS. So, anybody have any actual technical comments about this proposal? Yes. pioto's proposal is weak. lu_zero's counterproposal for developing a method of having a package manager agnostic API is much more useful than developing one language binding for one package manager. Weird, I haven't received Mike's e-mail yet, although I got ciaranm's reply. In any event, I agree that lu_zero's idea would be preferable, if it could be implemented. I'm agnostic on that point at the moment, though, since it's hard to evaluate from lu_zero's brief sketch. I'd love to see a true detailed proposal. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpslit9OK2hx.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Mike Kelly wrote: On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Yes. pioto's proposal is weak. You mean Piotr, right? He's a different person from me. I do. -- === Mike Doty kingtaco -at- gentoo.org Gentoo Council Gentoo Infrastructure Gentoo/AMD64 Strategic Lead GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
I'm very strongly against using Gentoo SoC time and resources for things that are not officially part of Gentoo (yes, this statement could be spun however you wish) or are not official Gentoo projects. And no, just because a project has Gentoo developers in it doesn't mean that it's a Gentoo project -- let's avoid the gray areas now, shall we? Just because we have Gentoo devs who are also Gnome upstream doesn't make their Gnome-related packages that happen to be in our tree official Gentoo projects. In my opinion, any project that has reasonable potential to improve Gentoo as a whole *and* is strongly related to Gentoo should be considerable for SoC. While this is certainly not the case for say Improving gtk+, it definitely is for Pepers project. After all, what is PMS all about, if we keep on evaluating package managers solely on being official Gentoo projects or not? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ciaran McCreesh wrote: Assuming you mean piotr, who is not pioto... The difference is, piotr's proposal is possible and doable within the timeframe, whereas lu_zero's sounds nice if you don't know anything about any of the package managers in question and can't be delivered within three months. I'd like to know your opinion about which are the pitfalls and the issues since you are surely more informed than me on paludis and, to a large degree, on portage internals. I assumed that for a foundation and a non exaustive converage the summer would be more than enough. I'm more interested in a solid base than a complete and exaustive wrapper =) lu PS: if the other project leaders would like to chip in I wouldn't be offended ^^ -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Josh Saddler wrote: We should not have third-party projects be part of SOC I see 3 important points missing from the discussion so far: (not directed at any response in particular) 1. We mentored projects like Piotr's last year, it seemed to work OK and as far as I'm aware there weren't any objections or conflicts of interest or anything like that. 2. Google are paying *GENTOO* $500 per project. Be sure to consider this when you state that mentoring projects like Piotr's would be taking resources away from Gentoo. 3. We should ask Google for their opinion on this. They are, after all, running the scheme, PAYING US MONEY, and are the people who decide whether we get to participate in future years. I have asked Alec to inquire about this. It seems that the mentors are already decided about the strategy here -- prefer projects undoubtedly in line with Gentoo development, but let proposal quality be the ultimate factor. My personal opinion is that we shouldn't be so hard on proposals like Piotr's. After all we are an open source community, the whole scheme is about promoting open source, so we should try and be open in our processes. In this particular case, it hasn't been decided that Paludis can't ever become the package manager of choice, and even while it isn't the official package manager right now, it is already helping significantly with areas like technical QA. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ciaran McCreesh wrote: Assuming you mean piotr, who is not pioto... The difference is, piotr's proposal is possible and doable within the timeframe, whereas lu_zero's sounds nice if you don't know anything about any of the package managers in question and can't be delivered within three months. I'd like to know your opinion about which are the pitfalls and the issues since you are surely more informed than me on paludis and, to a large degree, on portage internals. I assumed that for a foundation and a non exaustive converage the summer would be more than enough. I'm more interested in a solid base than a complete and exaustive wrapper =) lu PS: if the other project leaders would like to chip in I wouldn't be offended ^^ I'd imagine portage lacks many of the things that would be wrapped (multiple repos being probably the big killer). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ciaran McCreesh wrote: Which is all very nice in theory, but completely impractical and useless in practice. There's far too much difference and far too much complexity implementation-wise to make this practical for any non-trivial functionality. I'd like to have more details, please. Trivial functionality would be already fine for most of the front-ends IMHO. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Grant Goodyear wrote: Ciaran McCreesh wrote: [Sat Mar 24 2007, 11:38:45AM CDT] On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Grant Goodyear wrote: [snip] PS. So, anybody have any actual technical comments about this proposal? Yes. pioto's proposal is weak. lu_zero's counterproposal for developing a method of having a package manager agnostic API is much more useful than developing one language binding for one package manager. Weird, I haven't received Mike's e-mail yet, although I got ciaranm's reply. Me neither, but the mail is here: http://article.gmane.org/gmane.linux.gentoo.devel/47260 The bug: https://bugs.gentoo.org/141904 Regards, Robert signature.asc Description: OpenPGP digital signature
