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
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
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
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
> 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
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? -- 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: > 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, 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 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 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
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 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
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 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 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, 30 Mar 2007 21:23:32 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > 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. Then kindly stop interchanging Portage with Gentoo which you seem to do on a frequent basis. Thanks Roy -- gentoo-dev@gentoo.org mailing list
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 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 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, 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 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
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. > > >> "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
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. "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 -- 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
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
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
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 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 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 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 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
> 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 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
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 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 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, 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 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 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, 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, 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 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 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 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 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 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, 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
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
-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
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
> 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
> 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
Hi Seemant, On 30-Mar-07, at 6:28 AM, Seemant Kulleen wrote: Historical reasons aren't necessarily the correct reasons. I'd almost say that your sentence has officially heralded the age of Debianisation. There are practical reasons too. Like the fact that all of our users are now using portage, and making a switch is clearly a non-trivial issue, which has to be well thought out. 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. I agree. What are you basing any of this on? Sounds like speculation that doesn't help anything. 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. Debian was never a distro that I thought we'd emulate, or should emulate. Turns out I was wrong, I suppose. I'm not saying we should emulate Debian, but rather conveying the fact that, whether we like it or not, they're the only distro that we can really compare ourselves with. Of course, given a situation, there's more than one way to solve a problem; so we don't have to emulate them. I for one, sure don't want to, because I know there are many of us who've "run away" from Debian into the arms of Gentoo :) 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? I base that on the fact that all developers are more or less "equally" capable of making a technical decision. Maybe I am wrong. 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 ;) 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. 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? In sum, I'm not sure I like this direction of basing technical things on political decisions. 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? Thanks and Best Regards, -- Anant -- 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, 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 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, 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
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 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
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, 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
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 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 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 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 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 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 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
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 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
>>> 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 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
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
> 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
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
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
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 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
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 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 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
Ciaran McCreesh wrote: [a succinct enough, yet complete examination of the problems and the possible outcomes of my SoC idea] Thank you for pointing all the issue and give a good review of the 3 package managers. Now I think it's up to the students and front-end developers telling their wishes. 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 3/24/07, Daniel Drake <[EMAIL PROTECTED]> wrote: 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. This is by far the most pragmatic approach I've seen so far. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 24 Mar 2007 20:25:45 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > 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. If you're wanting to do a very simple API supporting approximately the following, you're ok: * Fetching a list of package versions that match a particular dependency atom * Fetching a list of available packages * Simple metadata queries upon a particular package * Fetching the contents of a particular package If you're wanting to make a powerful API that lets people solve real world problems, you're in for an awful lot of trouble. The problem is this... Although Paludis, Pkgcore and Portage solve the same ultimate problem, they do it in extremely different ways. Internally and from a public API perspective, there's very little in common between the three. Portage is by and large procedural and messy. It's basically an incoherent bunch of routines to do particular things. It doesn't generalise well, and things you'd expect to be similar aren't (e.g. you'd think finding out something about a package in VDB would be the same as finding out something about a package in the tree, but that would be far too easy...). Paludis is basically what you'd expect from a highly OO, resource managed language like C++. The problem is, a generalised API would end up hiding nearly all of the flexibility and functionality. You also can't wrap Paludis in any programming language that doesn't do resource management of some kind (preferably fully controlled, but since only C++ offers that, garbage collected works too). Writing a common middle layer in C and then writing language extensions on top of that isn't doable -- the common middle layer would have to be C++, since you can't write Ruby extensions in Python or suchlike... Pkgcore is closer to being AO than OO, largely because of programming language differences. Again, a generalised API would mask flexibility and functionality. You'd have a hard time getting callbacks to generalise cleanly. Design issues aside, there're also problems conceptually. The three package managers have very different ideas of certain key concepts like repositories, packages, the general operating environment (or domain) and version metadata. You'd have to come up with a whole new conceptual model that can handle all three paradigms, and you'd have to do it in such a way that you don't kill the performance techniques (delayed and batch loading, effectively) used by Paludis and Pkgcore. So it's down to a question of scope. Are you trying to make an API to do a few very basic queries, or are you trying to make an API powerful enough to, say, make a graphical front end? The former is doable and useless, the latter is a massive project. Now, what you *could* do is implement a portageq-style tool with more functionality. You'd still have conceptual issues (Paludis doesn't particularly like giving you global configuration information, for example -- simple things like querying whether a USE flag is enabled need an associated c/p-v::r), but they wouldn't be as bad. Such a tool would be slow, of limited use and easily doable within the available time. > I'm more interested in a solid base than a complete and exaustive > wrapper =) Which is the problem... The base is extremely different for all three. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Danny van Dyk wrote: > > * Paludis supports multiple repositories, don't know about pkgcore, but > i guess they support it as well. Portage doesn't. (actually it has 3 > repositories, but that's not really related to multiple repository > support) and mixing overlays and repository doesn't look that good even if it could be a possible temporary solution ^^; > > * Paludis handles ENVVARs on a per package basis, Portage doesn't. > (no idea about how pkgcore does it) Ok ^^ > > * Paludis repositories aren't necessarily ebuild repositories. I know =) > > This is what comes to my mind right now. The list is certainly not > complete :-) Well I think there is a huge list of advanced features already implemented and working well in paludis, but, my interest is in getting a basic wrapper so people writing front-ends could just have some high level abstraction for now and then cover what's advanced later. The abstraction MUST be something better than having pcre parsing the output of the PM default front-ends, but not that much ^^; 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
Am Samstag, 24. März 2007 20:53 schrieb Luca Barbato: > 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. * Paludis supports multiple repositories, don't know about pkgcore, but i guess they support it as well. Portage doesn't. (actually it has 3 repositories, but that's not really related to multiple repository support) * Paludis handles ENVVARs on a per package basis, Portage doesn't. (no idea about how pkgcore does it) * Paludis repositories aren't necessarily ebuild repositories. This is what comes to my mind right now. The list is certainly not complete :-) 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
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
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
> 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
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 ^^ -- 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
> 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
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
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
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
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: > 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
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 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
