[gentoo-dev] [soc] Python bindings for Paludis

[gentoo-dev] [soc] Python bindings for Paludis

[Piotr Jaroszyński]

Hello,

I have already submitted my application, but want to advertise it over here 
too :] Comments are welcome!

Summary:
Create Python bindings, associated documentation and test cases for the 
Paludis public API, and allow subclassing of Paludis classes using Python.

Detailed description:
http://dev.gentoo.org/~peper/soc/application.txt

P.S. I am aware of my imperfect English so will appreciate any grammar 	
comments, preferably on irc.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Josh Saddler]

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

Piotr Jaroszyński wrote:
> Hello,
> 
> I have already submitted my application, but want to advertise it over here 
> too :] Comments are welcome!
> 
> Summary:
> Create Python bindings, associated documentation and test cases for the 
> Paludis public API, and allow subclassing of Paludis classes using Python.
> 
> Detailed description:
> http://dev.gentoo.org/~peper/soc/application.txt


We should not have third-party projects be part of SOC -- specifically,
things that are not Gentoo projects. I'd lobby this whether it was
pkgcore or paludis being proposed, so don't bother trying to pin
partisan accusations. Point is, it's not a Gentoo project. PMS, portage
tests, or doing a gentoo.org rewrite -- those are Gentoo projects by any
reasonable standards, I should think.

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.

No third-party non-Gentoo SoC projects leeching off our organization and
resources, please. This includes third-party package managers and
third-party packages. You want free work, go get it via some other
entity, not our SoC.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Jonathan Adamczewski]

Josh Saddler wrote:
> 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

A Gentoo developer that is also a Gnome developer that wants to mentor a 
project to better integrate Gentoo and Gnome (in some way) would be 
appropriate.  Just like the proposed Java-related projects are 
appropriate - facilitating a better Gentoo/Java experience.

Paludis is a tool used for working with the Gentoo Portage tree - there 
is no problem with it being part of a Gentoo Google Summer of Code 
project as it will benefit the Gentoo project and its users.


 > No third-party non-Gentoo SoC projects leeching off our organization 
and resources, please.

You've got that backwards.  This is a potential SoC student who wants to 
*give* something to Gentoo (and Paludis).  No one is leeching anything.

j.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Wernfried Haas]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

On Sat, Mar 24, 2007 at 01:46:45PM +1100, Jonathan Adamczewski wrote:
> Paludis is a tool used for working with the Gentoo Portage tree - there is no problem with it being part of a Gentoo Google Summer of 
> Code project as it will benefit the Gentoo project and its users.

Why not simply solve the situation by making paludis the mentoring
organisation instead of Gentoo?

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Alec Warner]

> On Sat, Mar 24, 2007 at 01:46:45PM +1100, Jonathan Adamczewski wrote:
>> Paludis is a tool used for working with the Gentoo Portage tree - there
>> is no problem with it being part of a Gentoo Google Summer of
>> Code project as it will benefit the Gentoo project and its users.
>
> Why not simply solve the situation by making paludis the mentoring
> organisation instead of Gentoo?

You assume that the paludis folks applied for mentoring org status and
were accepted; which didn't happen.

The Gentoo SoC team is aware of lingering issues regarding projects like
pkgcore and paludis and whatnot.  I'd prefer we rank applications (and
applicants) based on the merits of their application as opposed to some
arbitrary political system.  If it happens that someone submits a very
well thought out idea with defined goals, milestones, has a design plan
and seems to have decent merit but happens to be say, a paludis related
project; well I guess the other people should have submitted better
proposals.  In the end most of the ranking and chosing of projects is a
huge judgement call by the SoC team and the mentors each year anyway.

Personally I think python bindings for paludis push the boundaries of
'does this project affect gentoo' while say, the project idea for 'adding
an ebuild development tool for paludis' does not push the boundaries.  One
is only tangentially related (paludis happens to be a tool that uses
ebuilds) and the other could be more of a cross-project project, with 1
gentoo mentor and 1 paludis mentor.  However my opinon (and most of this
ensuing discussion) is probably better served for when applications are
actually ranked.  So in closing, we know, some of us don't care, we will
disuss it during ranking.

-Alec

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Wernfried Haas]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

On Sat, Mar 24, 2007 at 01:31:08AM -0700, Alec Warner wrote:
> [some stuff]

Thanks for the explanation, i guess that makes sense.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

On Friday 23 March 2007, Josh Saddler wrote:
> I'm very strongly against using Gentoo SoC time and resources for things
> that are not officially part of Gentoo (yes, this statement could be
> spun however you wish) or are not official Gentoo projects. And no, just
> because a project has Gentoo developers in it doesn't mean that it's a
> Gentoo project -- let's avoid the gray areas now, shall we? Just because
> we have Gentoo devs who are also Gnome upstream doesn't make their
> Gnome-related packages that happen to be in our tree official Gentoo
> projects.

i'd have to agree here
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

On Sat, Mar 24, 2007 at 01:50:19AM -0400, Mike Frysinger wrote:
> On Friday 23 March 2007, Josh Saddler wrote:
> > I'm very strongly against using Gentoo SoC time and resources for things
> > that are not officially part of Gentoo (yes, this statement could be
> > spun however you wish) or are not official Gentoo projects. And no, just
> > because a project has Gentoo developers in it doesn't mean that it's a
> > Gentoo project -- let's avoid the gray areas now, shall we? Just because
> > we have Gentoo devs who are also Gnome upstream doesn't make their
> > Gnome-related packages that happen to be in our tree official Gentoo
> > projects.
> 
> i'd have to agree here
> -mike
Ditto. Gentoo SoC projects need to be for Gentoo developed and sponsored
code/projects, not third party projects, no matter how much they would whither
and die without a gentoo core. There was an example of gentoo+gnome integration
(i think) in a previous email - that wouldn't be any more appropriate. Unless
there's the Gentoo Inc copyright in the header, it isn't eligible in my opinion.

~mcummings, the other mike


-- 

-----o()o----------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-----o()o----------------------------------------------

Hi, I'm a .signature virus! Please copy me in your ~/.signature.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Piotr Jaroszyński]

On Saturday 24 of March 2007 13:54:51 Michael Cummings wrote:
> Ditto. Gentoo SoC projects need to be for Gentoo developed and sponsored
> code/projects, not third party projects, no matter how much they would
> whither and die without a gentoo core. There was an example of gentoo+gnome
> integration (i think) in a previous email - that wouldn't be any more
> appropriate. Unless there's the Gentoo Inc copyright in the header, it
> isn't eligible in my opinion.

Anant really meant his mail:

https://wiki.ubuntu.com/GoogleSoC2007
- Revision-controlled home directories - we have the same idea for /etc
- Python Basics Training Program
- Math System for Children
- Educational Apps
- Tool for computer aided vocabulary learning
- Gnome Media Center - G-Playah
...

Also Google FAQ is worth reading:
http://code.google.com/support/bin/answer.py?answer=60291

Google seems to concern more about the FOSS community than the organizations' 
copyright in the header and imho that's a good thing. Gentoo is supposed to 
be a _mentoring_ organization, so the only question is whether Gentoo mentors 
are capable of mentoring a project or not.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] YA_non-technical post about development (was Re: [soc] Python bindings for Paludis)

[Steve Long]

Piotr Jaroszy?ski wrote:
> On Saturday 24 of March 2007 13:54:51 Michael Cummings wrote:
>> Ditto. Gentoo SoC projects need to be for Gentoo developed and sponsored
>> code/projects, not third party projects, no matter how much they would
>> whither and die without a gentoo core. There was an example of
>> gentoo+gnome integration (i think) in a previous email - that wouldn't be
>> any more appropriate. Unless there's the Gentoo Inc copyright in the
>> header, it isn't eligible in my opinion.
<..> 
> Google seems to concern more about the FOSS community than the
> organizations' copyright in the header and imho that's a good thing.
> Gentoo is supposed to be a _mentoring_ organization, so the only question
> is whether Gentoo mentors are capable of mentoring a project or not.
> 
Umm there clearly isn't any consensus on that last phrase. Other devs appear
concerned about Gentoo copyright, which seems reasonable given the
requirement to maintain the interests of the distro as a whole.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 6120 bytes --]

Michael Cummings wrote: [Sat Mar 24 2007, 07:54:51AM CDT]
> On Sat, Mar 24, 2007 at 01:50:19AM -0400, Mike Frysinger wrote:
> > On Friday 23 March 2007, Josh Saddler wrote:
> > > I'm very strongly against using Gentoo SoC time and resources for things
> > > that are not officially part of Gentoo (yes, this statement could be
> > > spun however you wish) or are not official Gentoo projects. And no, just
> > > because a project has Gentoo developers in it doesn't mean that it's a
> > > Gentoo project -- let's avoid the gray areas now, shall we? Just because
> > > we have Gentoo devs who are also Gnome upstream doesn't make their
> > > Gnome-related packages that happen to be in our tree official Gentoo
> > > projects.
> > 
> > i'd have to agree here
> > -mike
> Ditto. Gentoo SoC projects need to be for Gentoo developed and
> sponsored code/projects, not third party projects, no matter how much
> they would whither and die without a gentoo core. There was an example
> of gentoo+gnome integration (i think) in a previous email - that
> wouldn't be any more appropriate. Unless there's the Gentoo Inc
> copyright in the header, it isn't eligible in my opinion.

Okay, let me explain why I think all three of you have the wrong
idea here, although I have sympathy for your argument.

First, there's the issue that hosting projects that are only
tangentially related to Gentoo drains our resources.  To some
extent that's true, but it's a minimal effect.  What resources
are we talking about?  Infra provides cvs or svn for the SOC 
students, we have a gentoo-soc mailing list, and I suspect there
will be a gentoo-soc planet again.  Getting that set up requires
significant effort, but the difference in effort between 5 students
and 10 students is not very much.  (One could imagine web-based
projects that would also require Infra to provide various web-based
or network-based apps, but those are likely to be for true Gentoo projects,
so I'm discounting those for this discussion.)  Gentoo also provides
mentors, who choose to volunteer their time.  If nobody wants to mentor
a project, it's not going to be accepted.  You could argue that by
allowing these sorts of projects we are encouraging devs to spend
time on non-Gentoo stuff.  *Shrug*  Our devs are volunteers, so I 
figure they're going to spend their time doing what they want to
do anyway.  (Incidentally, if that gnome+gentoo student chose to
submit his or her proposal to Gnome, nothing would stop one of our
devs from officially mentoring that person as long as the Gnome folks agreed
(or unofficially mentoring if they didn't).  

Of course, for many my above argument is beside the point.  It isn't
the resources, it's the principle of the thing.  SOC projects hosted
by Gentoo should be Gentoo projects that clearly benefit Gentoo and
have "(c) Gentoo Foundation, Inc" stamped on them.  I have sympathy
for that argument, but I respectfully disagree, because I think
that argument misses the essential point of Google's Summer of Code
program.  The primary goal is to get students involved in developing
open source code, and thus bringing new blood into the community.  Even
if our students don't become Gentoo developers, if they have a good
experience they are likely to be friendly to open-source software, at 
least, and perhaps even long-term active contributors.  My
view is that we are providing an altruistic service here to benefit
the community in which we reside, not to get free labor and a bit
of cash (Google pays the hosting organizations as well as the students).
(That said, we nonetheless did pick up some nice code and at least 
two devs from last year's program.  Also, our being chosen to participate
nicely enhances our reputation, both as being a significant player in
open-source and as being one of the "good guys" in the community.)

It's possible that I'm not being terribly convincing.  After all,
a student who submits a proposal to nmap is almost certainly going
to be working on nmap, not, say, honeynets.  Why should Gentoo
be different?  Well, for one thing, our main product is a 
distribution, and we spend most of our time integrating existing
code instead of writing new code, so we're pretty much a natural umbrella 
organization anyway.  Last year one of the proposals that was submitted
to a number of distributions (including ours) involved porting Sun's ZFS
to Linux.  It was a very well-written proposal, and it was accepted by
several different organizations.  (I don't remember which organization
he went with, but it wasn't Gentoo.)  Clearly having ZFS support in
Linux would benefit Gentoo in the long run, even if it wasn't an
obvious Gentoo project, and I'd have been perfectly happy supporting
it.  (In case you're curious, you can follow along the progress of
that proposal at http://zfs-on-fuse.blogspot.com/, and he just released
the first beta at the beginning of this month.)

Finally, let me be more specific about pkgcore- or paludis- or
gnome+gentoo-related proposals.  If not us as a mentoring org, who?  
They're clearly all Gentoo-related, even if not "pure" Gentoo projects
(whatever that means), and it's not as though somebody else is going
to pick them up....  

Feel free to tell me why I'm completely off my rocker.  It probably
wouldn't be the first time.

-g2boojum-

PS. So, anybody have any actual technical comments about this proposal?
    My personal opinion is that I wouldn't characterize it as a
    high-priority project for either Gentoo or Paludis, but the
    quality of the proposal itself is decent and real thought has been
    put into it.  (I can't figure out why this project would need both
    boost.python and the raw python C api, but that's just a detail.)
    Moreover, it also seems reasonable to me that a hard-working student
    could make real progress in this over the Summer.
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

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
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

On Sat, 24 Mar 2007 09:30:55 -0700
Mike Doty <kingtaco@gentoo.org> 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

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

Ciaran McCreesh wrote: [Sat Mar 24 2007, 11:38:45AM CDT]
> On Sat, 24 Mar 2007 09:30:55 -0700
> Mike Doty <kingtaco@gentoo.org> 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
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

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 <kingtaco@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Luca Barbato]

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

[Alec Warner]

> Ciaran McCreesh wrote:
>>
>> Assuming you mean piotr, who is not pioto... The difference is, piotr's
>> proposal is possible and doable within the timeframe, whereas lu_zero's
>> sounds nice if you don't know anything about any of the package
>> managers in question and can't be delivered within three months.
>
> I'd like to know your opinion about which are the pitfalls and the
> issues since you are surely more informed than me on paludis and, to a
> large degree, on portage internals.
>
> I assumed that for a foundation and a non exaustive converage the summer
> would be more than enough.
>
> I'm more interested in a solid base than a complete and exaustive wrapper
> =)
>
> lu
>
> PS: if the other project leaders would like to chip in I wouldn't be
> offended ^^

I'd imagine portage lacks many of the things that would be wrapped
(multiple repos being probably the big killer).


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

On Sat, 24 Mar 2007 20:25:45 +0100
Luca Barbato <lu_zero@gentoo.org> 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

[Luca Barbato]

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

[Piotr Jaroszyński]

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

[Mike Kelly]

On Sat, 24 Mar 2007 09:30:55 -0700
Mike Doty <kingtaco@gentoo.org> 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

[Mike Doty]

Mike Kelly wrote:
> On Sat, 24 Mar 2007 09:30:55 -0700
> Mike Doty <kingtaco@gentoo.org> 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

[Anant Narayanan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> We should not have third-party projects be part of SOC --  
> specifically,
> things that are not Gentoo projects. I'd lobby this whether it was
> pkgcore or paludis being proposed, so don't bother trying to pin
> partisan accusations. Point is, it's not a Gentoo project. PMS,  
> portage
> tests, or doing a gentoo.org rewrite -- those are Gentoo projects  
> by any
> reasonable standards, I should think.

Not entirely true. The very reason Google selects Linux Distributions  
as mentoring organizations is because a lot of projects that benefit  
the entire FOSS community in general are mentored by them. Have a  
look at the project ideas for Debian or Fedora; they have several  
ideas that have nothing to do with the distro, but do benefit a  
broader audience.

I see nothing wrong in mentoring projects that are not related to  
Gentoo in any way at all, leave alone projects like Paludis which  
have provide *direct* benefits for (some) Gentoo users.

I completely agree with what Alec says, applications must be ranked  
purely on the basis of their technical merit, rather than evaluating  
how it helps a specific subset of projects.

Cheers,
- --
Anant
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFGBRM9Ton3xA72kU4RAh5VAJ9/1DCzWqm5zMFyIPW6MccQEq1akQCgjOGk
0eiZGjA3Jw/ztUTuwTE/HQk=
=Zr/4
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Matthias Langer]

> 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 Frysinger]

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

On Sun, 25 Mar 2007 10:40:51 -0400
Mike Frysinger <vapier@gentoo.org> 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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

On Sunday 25 March 2007, Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Piotr Jaroszyński]

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

[Andrew Gaffney]

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 Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Piotr Jaroszyński]

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Michael Krelin]

> 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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On Tue, 27 Mar 2007 15:19:29 -0400
Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Tuesday 27 March 2007, Ciaran McCreesh wrote:
> On Tue, 27 Mar 2007 15:19:29 -0400
>
> Mike Frysinger <vapier@gentoo.org> 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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Anant Narayanan]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Thu, 29 Mar 2007 01:19:45 +0530
Anant Narayanan <anant@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Anant Narayanan]

On 29-Mar-07, at 2:26 PM, Ciaran McCreesh wrote:
> On Thu, 29 Mar 2007 01:19:45 +0530
> Anant Narayanan <anant@gentoo.org> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]

On Thu, 29 Mar 2007 22:46:14 +0530
Anant Narayanan <anant@gentoo.org> wrote:
> On 29-Mar-07, at 2:26 PM, Ciaran McCreesh wrote:
> > On Thu, 29 Mar 2007 01:19:45 +0530
> > Anant Narayanan <anant@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Thomas Rösner]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Thu, 29 Mar 2007 22:47:46 +0200
Thomas Rösner <Thomas.Roesner@digital-trauma.de> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Thomas Rösner]

Hi,

Ciaran McCreesh schrieb:
> On Thu, 29 Mar 2007 22:47:46 +0200
> Thomas Rösner <Thomas.Roesner@digital-trauma.de> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

On Fri, 30 Mar 2007 09:49:38 +0200
Thomas Rösner <Thomas.Roesner@digital-trauma.de> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Anant Narayanan]

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

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 3218 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Anant Narayanan]

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

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 4174 bytes --]

> 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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Anant Narayanan]

<snip>
> See above: not every developer is technically capable of evaluating  
> the
> underpinnings of the tools we use.  For most of us, those  
> underpinnings
> do not matter.

I find the reasoning to be quite justified.

> It's probably a little early to initiate such a proposal, seeing as  
> the
> PMS is still undergoing review.  Why don't we just let the current
> course of events continue, instead of trying to force any specific
> issue?  I'm sure that if the council decides to initiate a project to
> seriously pursue replacing portage as the official package manager,  
> they
> will take into account these repercussions of which you speak.  At the
> very least, you can bring them up at that time.

I look forward to using a better package manager then :)

Cheers,
--
Anant
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Vlastimil Babka]

-----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

[Alec Warner]

> On Thu, 29 Mar 2007 22:46:14 +0530
> Anant Narayanan <anant@gentoo.org> wrote:
>> On 29-Mar-07, at 2:26 PM, Ciaran McCreesh wrote:
>> > On Thu, 29 Mar 2007 01:19:45 +0530
>> > Anant Narayanan <anant@gentoo.org> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

On Thu, 29 Mar 2007 20:14:58 -0700 (PDT)
"Alec Warner" <antarus@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Andrej Kacian]

On Fri, 30 Mar 2007 13:55:55 +0100
Ciaran McCreesh <ciaranm@ciaranm.org> 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

[Roy Marples]

On Thu, 29 Mar 2007 18:50:59 +0100
Ciaran McCreesh <ciaranm@ciaranm.org> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Fri, 30 Mar 2007 21:13:18 +0100
Roy Marples <uberlord@gentoo.org> wrote:
> On Thu, 29 Mar 2007 18:50:59 +0100
> Ciaran McCreesh <ciaranm@ciaranm.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Christopher Sawtell]

On Saturday 31 March 2007, Ciaran McCreesh wrote:
> On Fri, 30 Mar 2007 21:13:18 +0100
>
> Roy Marples <uberlord@gentoo.org> wrote:
> > On Thu, 29 Mar 2007 18:50:59 +0100
> >
> > Ciaran McCreesh <ciaranm@ciaranm.org> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

On Sat, 31 Mar 2007 09:13:10 +1200
Christopher Sawtell <csawtell@paradise.net.nz> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

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




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Danny van Dyk]

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 <uberlord@gentoo.org> wrote:
> > > On Thu, 29 Mar 2007 18:50:59 +0100
> > >
> > > Ciaran McCreesh <ciaranm@ciaranm.org> 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 <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Christopher Sawtell]

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

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

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.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [soc] Python bindings for Paludis

[Steve Long]

Seemant Kulleen wrote:
> That's uncalled for.  There's no need to get nasty.

I applaud your intent, but feel it would have far more effect on the
atmosphere if applied to a few of your devs, rather than users who employ
milder terms?

It just seems knowingly unfair, and I don't believe that is your purpose.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Sat, 2007-03-31 at 23:39 +0100, Steve Long wrote:
> Seemant Kulleen wrote:
> > That's uncalled for.  There's no need to get nasty.
> 
> I applaud your intent, but feel it would have far more effect on the
> atmosphere if applied to a few of your devs, rather than users who employ
> milder terms?
> 
> It just seems knowingly unfair, and I don't believe that is your purpose.


Not getting into this.  If your intent is to undermine, please do it
privately.  If you're just trying to be inflammatory (as you seem to be
often), please put a stop to it *NOW*.  Like I've said before, just
because you know how to type an email and send it, doesn't mean you
*should*.  


You can check my posts to see me address anyone getting out of hand.

Thanks,

Seemant


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Christopher Sawtell]

On Sunday 01 April 2007, Seemant Kulleen wrote:
> On Sat, 2007-03-31 at 23:39 +0100, Steve Long wrote:
> > Seemant Kulleen wrote:
> > > That's uncalled for.  There's no need to get nasty.
> >
> > I applaud your intent, but feel it would have far more effect on the
> > atmosphere if applied to a few of your devs, rather than users who employ
> > milder terms?
> >
> > It just seems knowingly unfair, and I don't believe that is your purpose.
>
> Not getting into this.  If your intent is to undermine, please do it
> privately.  If you're just trying to be inflammatory (as you seem to be
> often), please put a stop to it *NOW*.
Seemant: Please, please, learn a bit about British English idiom.
Your gross over-reactions to both what I, and Steve Long, wrote indicate that 
while you have interpreted our words precisely, you have completely failed to 
appreciate the overall nuance of meaning in either message. Neither of which 
carries anything like the level of inflammatory obloquy which you seem to 
have deduced from them. I don't know who first uttered the phrase: "We are 
separated by our common language." or words to that effect, but I see the 
effect of it in postings to this list time and time again. It's a shame.

> Like I've said before, just because you know how to type an
> email and send it, doesn't mean you *should*. 
Indeed! You stole my very words!
A case for the thought police I do believe!

> You can check my posts to see me address anyone getting out of hand.
Not today, thank you.

For those readers who might have difficulty with this message, please rest 
assured that the second two paragraphs are intended to be jocular, and 
consult Princeton University's Wordnet system for precise meanings.

--
CS
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: [soc] Python bindings for Paludis

[Steve Long]

Seemant Kulleen wrote:
>> > That's uncalled for.  There's no need to get nasty.
>> 
>> I applaud your intent, but feel it would have far more effect on the
>> atmosphere if applied to a few of your devs, rather than users who employ
>> milder terms?
>> 
>> It just seems knowingly unfair, and I don't believe that is your purpose.
> 
> Not getting into this.  If your intent is to undermine, please do it
> privately.  If you're just trying to be inflammatory (as you seem to be
> often), please put a stop to it *NOW*.
<..>
Sorry, it was not to undermine at all, but rather to get some parity of
treatment for usrs as opposed to devs. I am more than willing to discuss
with you privately, however your _seeming_ bias which I am addressing has
been carried out publically. And if I am in fact to be moderated by the new
`asshat brigade', I would hope there would indeed be parity.

So: no, I am not trying to be inflammatory. Just to get the groundrules
sorted before those kinda comments from a core dev get me banned ;)

And yeah, Mr Sawtell has it right in at least one sense: you're overreacting
to what might to US ears be perceived as patronising, but in the UK is
simply careful language.

> You can check my posts to see me address anyone getting out of hand.
> 
I'm not saying that you are wrong in addressing the people that you have.
Rather that you allow much more derogatory and frankly unprofessional
comments from devs. In this same thread, I have seen much worse comments;
the example that comes to mind is Mike Frysinger's spat with ciaranm.

Much as I think Ciaran is trolling this list, and apparently has a bot
sending out EAPI data regarding Portage non-compliance one line at a time
(that was a joke), and further that someone who has been banned from gentoo
development should in fact automatically be banned from the public dev m-l,
I cannot say I have thought all of Mr Frsyinger's comments appropriate or
helpful. I was actually ignoring this thread, and only read more of it
because I saw such core devs (council members?) commenting.

I had hoped to read a much more level-headed debate about socio-political
aspects of development in a virtual community. Instead I again saw a dev
resort to IRC-type nastiness instead of starving a troll. I left that
sub-thread and read only your insightful comments; Duncan said all I wanted
to, far better than I would have, about the original topic of PMs.

Although, based on Mr Warner's post, the whole topic about SoC should have
been on another list. Shame amne can't just move it like he would have ages
ago in the forums..


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Roy Marples]

On Fri, 30 Mar 2007 21:23:32 +0100
Ciaran McCreesh <ciaranm@ciaranm.org> 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

[Ned Ludd]

On Thu, 2007-03-29 at 09:56 +0100, Ciaran McCreesh wrote:
> On Thu, 29 Mar 2007 01:19:45 +0530
> Anant Narayanan <anant@gentoo.org> 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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

On Thu, 29 Mar 2007 11:57:36 -0700
Ned Ludd <solar@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ned Ludd]

On Thu, 2007-03-29 at 20:06 +0100, Ciaran McCreesh wrote:
> On Thu, 29 Mar 2007 11:57:36 -0700
> Ned Ludd <solar@gentoo.org> 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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

On Thu, 29 Mar 2007 12:25:00 -0700
Ned Ludd <solar@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ned Ludd]

On Thu, 2007-03-29 at 21:02 +0100, Ciaran McCreesh wrote:
> On Thu, 29 Mar 2007 12:25:00 -0700
> Ned Ludd <solar@gentoo.org> 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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Stephen Bennett]

On Thu, 29 Mar 2007 13:33:31 -0700
Ned Ludd <solar@gentoo.org> 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

[Ilya A. Volynets-Evenbakh]

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

[Ned Ludd]

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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3942 bytes --]

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 <Thomas.Roesner@digital-trauma.de> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3462 bytes --]

On Fri, 30 Mar 2007 02:07:33 -0700
Brian Harring <ferringb@gmail.com> 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 <Thomas.Roesner@digital-trauma.de> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2970 bytes --]

On Fri, 30 Mar 2007 14:04:15 -0400
Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Homer Parker]

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 <hparker@gentoo.org>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Fri, 30 Mar 2007 13:50:39 -0500
Homer Parker <hparker@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Michael Krelin]

> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On Fri, 30 Mar 2007 22:41:47 +0200
Michael Krelin <gentoodoo@klever.net> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Michael Krelin]

>>> 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

[gentoo-dev] Re: [soc] Python bindings for Paludis

[Steve Long]

Michael Krelin wrote:
>> The question is whether scripts that, say, parse emerge -pv output have
>> to carry on working. 
> 
> I think this requirement would put portage itself in quite uncomfortable
> situation.
> 
It's a non-issue imo; it's up to script authors and maintainers (aka users)
to keep up with whichever tools they choose, cf Bash 3.2 regex changes.
If it's a useful script, it'll get updated.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Michael Krelin]

> Michael Krelin wrote:
>>> The question is whether scripts that, say, parse emerge -pv output have
>>> to carry on working. 
>> I think this requirement would put portage itself in quite uncomfortable
>> situation.
>>
> It's a non-issue imo; it's up to script authors and maintainers (aka users)
> to keep up with whichever tools they choose, cf Bash 3.2 regex changes.
> If it's a useful script, it'll get updated.

I think the same applies not only for different portage versions, but
for various package managers too. There may be some parts of the output
strictly specified, but otherwise it's like indeed forcing all
sendmail-compatible mailers provide uniform mailq output.

Love,
H
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Larry Lines]

On Fri, 2007-03-30 at 19:35 +0100, Ciaran McCreesh wrote:
> On Fri, 30 Mar 2007 14:04:15 -0400
> Mike Frysinger <vapier@gentoo.org> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On Fri, 30 Mar 2007 15:30:31 -0500
Larry Lines <larry@twistedpop.com> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 3692 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3724 bytes --]

On Fri, 30 Mar 2007 16:51:54 -0400
Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 3784 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2338 bytes --]

On Fri, 30 Mar 2007 20:29:46 -0400
Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

On Fri, 30 Mar 2007 21:03:14 -0400
Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Anant Narayanan]

Hi Mike,

On 31-Mar-07, at 2:21 AM, Mike Frysinger wrote:
> not really, why dont you apply some of your logic:
>  - you are not wanted as an official Gentoo developer ... the past  
> clearly
> shows this
>  - the official package manager of Gentoo would need to be
> completely "in-house" with respect to control, direction, etc...
>  - "in-house" would require every one who is control of the package  
> manager to
> be a Gentoo developer
>  - in order for you to gain @gentoo.org again, we'd need either a  
> complete
> flush of developer blood who would accept you or you to change  
> yourself ...
> neither of which are realistic
>
> so let's put this all together shall we:
> you are in full control of paludis,  you will not be a Gentoo  
> developer,
> thereforce paludis will not be the official Gentoo package manager

The logic is flawed. I don't understand why Gentoo can't switch to  
paludis so long as there are "in-house" Gentoo developers ready to  
maintain and support it.

<snip>
> "emerge" is a brand name for Gentoo and while you can complain  
> about lack of
> features all you want, dropping portage and installing a different  
> package
> manager with a completely different interface will surely causes a  
> huge pita
> for everyone

It is a rather trivial issue to wrap paludis or pkgcore commands to  
their "emerge" equivalents. As discussed before on the thread, mere  
command-line compatibility is not an issue at all. If a switch is  
made to a new package, I am sure enough steps will be taken to ensure  
that the process is as transparent as possible, and most users will  
not even notice the difference; except of course the immediate benefits.

Cheers,
--
Anant
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Josh Saddler]

[-- Attachment #1: Type: text/plain, Size: 2622 bytes --]

Anant Narayanan wrote:
> Hi Mike,
> 
> On 31-Mar-07, at 2:21 AM, Mike Frysinger wrote:
>> not really, why dont you apply some of your logic:
>>  - you are not wanted as an official Gentoo developer ... the past
>> clearly
>> shows this
>>  - the official package manager of Gentoo would need to be
>> completely "in-house" with respect to control, direction, etc...
>>  - "in-house" would require every one who is control of the package
>> manager to
>> be a Gentoo developer
>>  - in order for you to gain @gentoo.org again, we'd need either a
>> complete
>> flush of developer blood who would accept you or you to change
>> yourself ...
>> neither of which are realistic
>>
>> so let's put this all together shall we:
>> you are in full control of paludis,  you will not be a Gentoo developer,
>> thereforce paludis will not be the official Gentoo package manager
> 
> The logic is flawed. I don't understand why Gentoo can't switch to
> paludis so long as there are "in-house" Gentoo developers ready to
> maintain and support it.
> 
> <snip>
>> "emerge" is a brand name for Gentoo and while you can complain about
>> lack of
>> features all you want, dropping portage and installing a different
>> package
>> manager with a completely different interface will surely causes a
>> huge pita
>> for everyone
> 
> It is a rather trivial issue to wrap paludis or pkgcore commands to
> their "emerge" equivalents. As discussed before on the thread, mere
> command-line compatibility is not an issue at all. If a switch is made
> to a new package, I am sure enough steps will be taken to ensure that
> the process is as transparent as possible, and most users will not even
> notice the difference; except of course the immediate benefits.
> 
> Cheers,
> -- 
> Anant
> --gentoo-dev@gentoo.org 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Matthias Langer]

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

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

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.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Rumen Yotov]

Hi,
On Fri, 30 Mar 2007 15:28:52 -0400
Seemant Kulleen <seemant@gentoo.org> 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

[gentoo-dev] Re: [soc] Python bindings for Paludis

[Duncan]

Seemant Kulleen <seemant@gentoo.org> posted
1175282932.5964.9.camel@localhost, excerpted below, on  Fri, 30 Mar 2007
15:28:52 -0400:

> 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.

Your replies always seem so... calm and sane.  Thanks.


I keep seeing references to an "official" package manager.  Clearly, at 
this point, it's portage, in part because there was no other practical 
reference for deciding whether the ebuild or the handling of it was 
broken.  If it worked in portage, therefore, by definition, it was fine.  
(Well, with certain exceptions where portage was held to have bugs, but 
whether it was a bug in portage or not had to be decided before one could 
then rule on whether it was a bug in the tree or not.)

However, now that PMS is finally about to provide what should be a 
definitive description of current generation package behavior, with the 
announced intention to update this with new versions into the future as 
required, the dependence on portage as the reference will soon be going 
away.  The announced intention for this, among other things, is to allow 
alternate package managers, such that it can still be clear when it's the 
package broken and when it's the package manager.  

So far, so good.  However, with such a definitive package behavior 
reference, the question presents itself, with what looks to be several 
possible alternatives waiting, why must Gentoo have an "official" package 
manager at all, and indeed, what purpose, other than name recognition, 
does maintaining such an "official" manager have?

I'd contend that with an appropriate package/tree spec, as soon as we 
have multiple package managers meeting that spec, then we /don't/ /need/ 
an "official" package manager.  Perhaps one /recommended/ by default in 
the documentation, sure.  Perhaps one that ships on the official Gentoo 
LiveCD installers, sure.  However, all this arguing over "official" 
package manager is worthless, IMO.  Let the alternatives each stand on 
their own merits, just as we do with all sorts of other choices, 
optionally with one recommended for newbies who don't have any reason of 
their own to prefer one over another and likely with one used to build 
official media, but without any of them recognized as the /official/ 
package manager, because there's simply no continuing need for such a 
thing, once the extents and limits of acceptable package behavior at a 
particular API level has been appropriately speced out.

If this approach were taken, it wouldn't have to affect releng much at 
all, certainly short term, since they could continue using portage, which 
is assumed to continue to be one of the recognized and accepted 
alternatives.  Longer term, it would only as they found reason to switch 
to other alternatives, and if they didn't find such reason, well...  It 
would affect bugs very little as well, since there are already bugs where 
it ends up being a package manager regression, only now, such regressions 
would be measured against the package spec, rather than against past 
behavior of any particular package manager (except as necessarily encoded 
in that spec, for the first version, anyway), and there'd now be a 
definitive way to say for sure whether it was the package manager or the 
package.

Documentation, there'd necessarily be some adjustment.  However, the 
documentary focus could remain on the "recommended" package manager, 
referring to the individual manager's documentation if they'd made a 
choice other than the "recommended" choice.  Certainly, it would behoove 
the maintainers of alternative package managers to create compatible 
documentation if they wished to go very mainstream, but nothing would 
force the docs project into massive changes except as such docs were 
ready and then only in cooperation with the arch teams and releng re the 
recommendations in the handbook.

What about infra?  What about Mike's worry of securing Gentoo access to 
at least one of its package managers?  How about this?  Maybe it has 
holes in it, but it should provide at least a minimum security level, and 
combined with an "open" package manager spec encouraging multiple 
alternative implementations, I think it's likely to be found workable in 
practice.  Require for any "approved" package manager, not that the 
working repository /has/ to reside on Gentoo infrastructure, but that a 
repository mirror, routinely updated every 24 hours at minimum, be 
maintained on Gentoo infra.  For approval, this must be a /complete/ 
mirror.  However, if appropriate and necessary, it may be restricted 
access.  (Hash out the requirement further as necessary, but the idea 
being that if access is restricted, the council and probably at least one 
member of Gentoo security must have access.)  For approval, the license 
would be required to be be acceptably open to allow a fork if necessary, 
and presumably at least one Gentoo developer on the package manager 
development team wouldbe required as well, with two or more encouraged to 
prevent issues due to retirements or the like.  (If the number of 
approved package managers should ever exceed three, access and Gentoo dev 
requirements may be relaxed as found appropriate.)

In summary, there would be no "official" Gentoo package manager as such, 
but ideally, several "approved" managers, plus perhaps some in the 
community not officially approved.  Recommendations would however be 
allowed, with docs presumably favoring the recommended option, and releng 
free to use what they felt best in cooperation with the various teams 
they work with.  PM/pkg bug responsibility would be according to the 
official package spec.  Package managers wouldn't be required to be 
developed on Gentoo infrastructure, but for official approval, if the 
repository were not on Gentoo infra, a repository mirror on Gentoo infra 
would be required.  If the package manager were independently developed, 
appropriate licensing and the presence of a Gentoo developer on the 
package manager development team, thus ensuring continued continuity for 
Gentoo should the independent project dry up and blow away or the like, 
would be necessary for approval.  Approval requirements may be relaxed to 
some degree if the number of approved alternatives is found to be enough 
to eliminate danger of shortage.

I'm sure there are holes in the above, there always are in first drafts.  
However, I just don't see it necessary to squabble over the status of 
"official" package manager after introduction of a suitable package spec, 
because I see no reason for there to /be/ such an "official" package 
manager, but rather a group of "officially approved" managers, given that 
options exist, with approval contingent on reasonable implementation of 
the package spec among other things, of course.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Adam Pickett]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello;

	I'm just a gentoo user who has been lurking for a while trying to find
a useful way to help my linux distro. Gentoo was recommended to be as a
good way to get into linux and to rapidly understand the difference
between the way linux works and windows works.
I have to say that for the two years of my university life that i have
used Gentoo for it has taught my a lot.

Now i have never had a problem with portage my self, but since this
thread is in existence there are some definite issues.

Myself as a user would very much have to support Duncan's post below and
as a Computer Science grad would have to say that it makes sense to
clearly define a PMS which should be swappable 1:1 with any other PMS.
To help new users the basic command set should also be the same, tho of
course  each PMS can have its own advanced features.

Finally my own personal view of this matter; Gentoo should have and
support its own package manager, it makes sense since one of the key
advantages of Gentoo is to just have to packages you need with just to
support you need i.e. USE flags. Since this is a key goal of the gentoo
project it makes sense to provide a 'default' PM which abides to the
PMS. It also means that there will always be a secure, monitored,
distribution maintained package manager which would guarantee the
distributions basic functionality.

Well there is my 'users' point of view;

As a quick aside, could someone point me in the right direction to help
out with Gentoo, I've got some skills in C and C++ tho my main language
is Java, but I'm a quick learner :P

Duncan wrote:
> 
> I keep seeing references to an "official" package manager.  Clearly, at 
> this point, it's portage, in part because there was no other practical 
> reference for deciding whether the ebuild or the handling of it was 
> broken.  If it worked in portage, therefore, by definition, it was fine.  
> (Well, with certain exceptions where portage was held to have bugs, but 
> whether it was a bug in portage or not had to be decided before one could 
> then rule on whether it was a bug in the tree or not.)
> 
> However, now that PMS is finally about to provide what should be a 
> definitive description of current generation package behavior, with the 
> announced intention to update this with new versions into the future as 
> required, the dependence on portage as the reference will soon be going 
> away.  The announced intention for this, among other things, is to allow 
> alternate package managers, such that it can still be clear when it's the 
> package broken and when it's the package manager.  
> 
> So far, so good.  However, with such a definitive package behavior 
> reference, the question presents itself, with what looks to be several 
> possible alternatives waiting, why must Gentoo have an "official" package 
> manager at all, and indeed, what purpose, other than name recognition, 
> does maintaining such an "official" manager have?
> 
> I'd contend that with an appropriate package/tree spec, as soon as we 
> have multiple package managers meeting that spec, then we /don't/ /need/ 
> an "official" package manager.  Perhaps one /recommended/ by default in 
> the documentation, sure.  Perhaps one that ships on the official Gentoo 
> LiveCD installers, sure.  However, all this arguing over "official" 
> package manager is worthless, IMO.  Let the alternatives each stand on 
> their own merits, just as we do with all sorts of other choices, 
> optionally with one recommended for newbies who don't have any reason of 
> their own to prefer one over another and likely with one used to build 
> official media, but without any of them recognized as the /official/ 
> package manager, because there's simply no continuing need for such a 
> thing, once the extents and limits of acceptable package behavior at a 
> particular API level has been appropriately speced out.
> 
> If this approach were taken, it wouldn't have to affect releng much at 
> all, certainly short term, since they could continue using portage, which 
> is assumed to continue to be one of the recognized and accepted 
> alternatives.  Longer term, it would only as they found reason to switch 
> to other alternatives, and if they didn't find such reason, well...  It 
> would affect bugs very little as well, since there are already bugs where 
> it ends up being a package manager regression, only now, such regressions 
> would be measured against the package spec, rather than against past 
> behavior of any particular package manager (except as necessarily encoded 
> in that spec, for the first version, anyway), and there'd now be a 
> definitive way to say for sure whether it was the package manager or the 
> package.
> 
> Documentation, there'd necessarily be some adjustment.  However, the 
> documentary focus could remain on the "recommended" package manager, 
> referring to the individual manager's documentation if they'd made a 
> choice other than the "recommended" choice.  Certainly, it would behoove 
> the maintainers of alternative package managers to create compatible 
> documentation if they wished to go very mainstream, but nothing would 
> force the docs project into massive changes except as such docs were 
> ready and then only in cooperation with the arch teams and releng re the 
> recommendations in the handbook.
> 
> What about infra?  What about Mike's worry of securing Gentoo access to 
> at least one of its package managers?  How about this?  Maybe it has 
> holes in it, but it should provide at least a minimum security level, and 
> combined with an "open" package manager spec encouraging multiple 
> alternative implementations, I think it's likely to be found workable in 
> practice.  Require for any "approved" package manager, not that the 
> working repository /has/ to reside on Gentoo infrastructure, but that a 
> repository mirror, routinely updated every 24 hours at minimum, be 
> maintained on Gentoo infra.  For approval, this must be a /complete/ 
> mirror.  However, if appropriate and necessary, it may be restricted 
> access.  (Hash out the requirement further as necessary, but the idea 
> being that if access is restricted, the council and probably at least one 
> member of Gentoo security must have access.)  For approval, the license 
> would be required to be be acceptably open to allow a fork if necessary, 
> and presumably at least one Gentoo developer on the package manager 
> development team wouldbe required as well, with two or more encouraged to 
> prevent issues due to retirements or the like.  (If the number of 
> approved package managers should ever exceed three, access and Gentoo dev 
> requirements may be relaxed as found appropriate.)
> 
> In summary, there would be no "official" Gentoo package manager as such, 
> but ideally, several "approved" managers, plus perhaps some in the 
> community not officially approved.  Recommendations would however be 
> allowed, with docs presumably favoring the recommended option, and releng 
> free to use what they felt best in cooperation with the various teams 
> they work with.  PM/pkg bug responsibility would be according to the 
> official package spec.  Package managers wouldn't be required to be 
> developed on Gentoo infrastructure, but for official approval, if the 
> repository were not on Gentoo infra, a repository mirror on Gentoo infra 
> would be required.  If the package manager were independently developed, 
> appropriate licensing and the presence of a Gentoo developer on the 
> package manager development team, thus ensuring continued continuity for 
> Gentoo should the independent project dry up and blow away or the like, 
> would be necessary for approval.  Approval requirements may be relaxed to 
> some degree if the number of approved alternatives is found to be enough 
> to eliminate danger of shortage.
> 
> I'm sure there are holes in the above, there always are in first drafts.  
> However, I just don't see it necessary to squabble over the status of 
> "official" package manager after introduction of a suitable package spec, 
> because I see no reason for there to /be/ such an "official" package 
> manager, but rather a group of "officially approved" managers, given that 
> options exist, with approval contingent on reasonable implementation of 
> the package spec among other things, of course.
> 

- --
.Adam Pickett

A.M.Pickett.1@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGD5VyApBPo0RrzjERAnELAKDKbrGdH5UcmXvq6hsYEsfpdylWnwCgzH7K
9StBe0V9EhxmH84D0snX8f0=
=CmP1
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> However, now that PMS is finally about to provide what should be a 
> definitive description of current generation package behavior, with the 
> announced intention to update this with new versions into the future as 
> required, the dependence on portage as the reference will soon be going 
> away.  The announced intention for this, among other things, is to allow 
> alternate package managers, such that it can still be clear when it's the 
> package broken and when it's the package manager.  

	From what I've read of the PMS, it currently only describes the input
format it would accept (namely the format for ebuild files and their
contents).  This question can be delayed until the PMS defines the
operation of the package manager, including but not limited to the
recording of installed package data.  If the package managers do not
agree on which packages are installed or how to uninstall them, then
they are not yet interchangeable.

	I apologize if this point has already been raised elsewhere in the
thread.  I try not to get involved in threads like this, but
accidentally read a reply and thought this might be a valuable response.

	Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)

iD8DBQFGD6/0u7rWomwgFXoRAiT9AKCV/+YGLba3owSWEt/cbOPbyC3YrgCfbboE
+oqnTwPBGzD7ORY15VwOxoo=
=I3ta
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [soc] Python bindings for Paludis

[Duncan]

Mike Auty <ikelos@gentoo.org> posted 460FAFF4.4060901@gentoo.org,
excerpted below, on  Sun, 01 Apr 2007 14:13:24 +0100:

> From what I've read of the PMS, it currently only describes the input
> format it would accept (namely the format for ebuild files and their
> contents).  This question can be delayed until the PMS defines the
> operation of the package manager, including but not limited to the
> recording of installed package data.  If the package managers do not
> agree on which packages are installed or how to uninstall them, then
> they are not yet interchangeable.
> 
> I apologize if this point has already been raised elsewhere in the
> thread.  I try not to get involved in threads like this, but
> accidentally read a reply and thought this might be a valuable response.

Thanks.  It is valuable (and hasn't been already raised to my 
observation).

As I understand it, they wouldn't necessarily be dynamically 
interchangeable, that is, on a live system (at least not without running 
some sort of conversion utility, which may or may not exist and may or 
may not "lose" some information in the conversion, defaulting the missing 
values).  Rather, one could choose one and run with it, and only change 
with some work and/or loss of data.

Practically speaking, at minimum, it is assumed the world file would 
normally either remain the same format or be convertible (automatically 
or by hand), and the USE flags would be convertible, so if install data 
were lost in the switch, one could at worst rebuild empty-tree world (in 
whatever PM lingo) to get the database in the new format if necessary.  
Thus, it's not something one would wish to switch back and forth willy 
nilly, but switching would be possible, with a bit of work.

Of course, that assumes a package manager that even has the concept of 
the world file, I'd guess a /relatively/ safe assumption (and some form 
of USE flag handling is required by the spec).  For those that didn't, 
well, a rather more painstaking individual package rebuild may be 
necessary to do the conversion.  However, one might suppose those would 
be corner cases, and if someone wanted to go to the trouble, well...

The point being, however, that all this quarreling about "official" 
package managers doesn't /really/ have to happen.  Arguing Ciaran's 
viewpoint for a moment, if portage really is /that/ bad and "future 
challenged", if official restrictions /do/ end up eliminating all other 
competition for official manager, well, it's entirely possible there'll 
be an official manager, and then there'll be the one (or more) everyone 
actually uses, again making arguing over an "official" PM "much ado about 
nothing".  That's one extreme.  At the other, the alternatives just never 
go mainstream, regardless of whether they are "officially blessed".  
Again, much ado about nothing.  In the middle, multiple managers prove 
functional and are chosen by a reasonable segment of Gentoo users, 
regardless of "official blessing" or not, and again, it matters little 
what the official status is.  I just don't see why so many are spending 
so much time arguing over it, when regardless, people are going to make 
their choices, and "official" status won't matter so much when people do 
so, because the package spec and what works is going to be the defining 
factor, not some "official" blessing, except indirectly as that affects 
further package spec updates.

If that makes any sense and isn't entirely circular... it does (and 
isn't) to me, anyway.  Certainly more so than what to me is pretty much 
bickering over nothing.  =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> The point being, however, that all this quarreling about "official" 
> package managers doesn't /really/ have to happen. [...]
>  I just don't see why so many are spending 
> so much time arguing over it, when regardless, people are going to make 
> their choices, and "official" status won't matter so much when people do 
> so, because the package spec and what works is going to be the defining 
> factor, not some "official" blessing, except indirectly as that affects 
> further package spec updates.

	I agree that the title "official" is nothing more than a title or label
and will most likely be applied to the most common/popular manager.  I
think the reason for the discussion is that arguably Gentoo has been
goal-less or at the very least major-project-less, and developers with
vision are nervously looking for the direction to push the project.
Personally, I'm very happy with Gentoo as is, it's flexible, I can add
the packages I might find when browsing the web and it does everything I
need.  I don't need a major direction, or a big change, or an upheaval,
or pretty much anything else, and I believe many of the less vocal
developers feel similarly.
	However, for those that are looking for a change (and sunrise and seeds
both seem recent evidence that a body of developers are looking for a
change), then I think the alternative package manager is a nice big area
with big uncertainty, given that it's well developed source-based
package management is arguably the unique selling point of Gentoo.  I
think if someone were writing a "new" portage that simply took over from
the old one one day, there would be nowhere near as much discussion.
Therefore, the issue at the heart of these threads is the possibility of
splintering of the project.
	There are quite clearly two sides.  Those that would like to see
multiple package managers: their reasoning is that they'd like to offer
an alternative, with features and designs that would be difficult to
integrate into the existing code, and some decisions that would break
with the current design (albeit slightly).  The other side doesn't
necessarily fear another, better package manager, but fears that
allowing multiple package managers will start to cause incompatibilities
and will divide both the user group and the developer group.  Overlays
are a feature capable of this division, and already it's given rise to
the "seeds" idea, which again met with the same dissent: that of divided
time and resources spent on a number of smaller Gentoos, each with less
popularity, less time devoted to each, and the difficulty of
re-integration with the main branch.
	Nobody actively wants to break the main tree, but no one has yet
figured out a way of ensuring that users do not encounter disruption if
they decide to use a different package manager.  The PMS is a step to
overcome this by defining a standard, or interface, to ensure compatibility.
	So how can we smooth the way between the two sides?  The best I can
come up with is a more complete specification.  One that includes both
the package format, and the local state required to store data.  The
Pros for this, are that package managers could become interchangeable,
to the point that it would never matter which package manager were in
use at the time.  The cons for this idea, are that it would slow down
the development, changes and feature additions to the various managers,
as the changes must first pass through the specification and then
finally be implemented.
	We've already seen (with the introduction of Manifest2) that changes to
the tree and distribution mechanism are slow at best (I believe manifest
signing is over two years old and still not in place for every
package?).  Requiring adherence to a specification, and maintaining that
specification will be even more difficult and slow, but it would allow
both sides to move on, and work together towards the new direction.
	So now the question is, are we willing to accept the cons for the pros,
or do we need to find a different solution.  If not, then other package
managers should invest their time in ratifying a specification quickly,
so that they can get down to coding to the specification.  Also, those
against a new manager, should get down to agreeing the specification so
that managers with the possibility of fracturing are bound within a
framework of acceptability.  As I see it, that leaves both sides working
towards the same direction, and should give impetus to both groups to
come to a common point as fast as possible.
	If not, then probably we should return to the drawing board, but I
concur that bickering and worrying about the future without pinpointing
the problem and trying to tackle it, is far more futile than working
towards a viable solution...
	Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)

iD8DBQFGEDWOu7rWomwgFXoRAl4bAJ9PHn6kzSB3ChzXer9+3dxm6nSj/gCfTAJ1
moZTFrQjlMqyUF2v54sz88E=
=A8vf
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [soc] Python bindings for Paludis

[Duncan]

Mike Auty <ikelos@gentoo.org> posted 46103599.9050408@gentoo.org,
excerpted below, on  Sun, 01 Apr 2007 23:43:37 +0100:

Snipped a lot of well stated opinion...

> So now the question is, are we willing to accept the cons for the pros,
> or do we need to find a different solution.  If not, then other package
> managers should invest their time in ratifying a specification quickly,
> so that they can get down to coding to the specification.  Also, those
> against a new manager, should get down to agreeing the specification so
> that managers with the possibility of fracturing are bound within a
> framework of acceptability.  As I see it, that leaves both sides working
> towards the same direction, and should give impetus to both groups to
> come to a common point as fast as possible.

> If not, then probably we should return to the drawing board, but I
> concur that bickering and worrying about the future without pinpointing
> the problem and trying to tackle it, is far more futile than working
> towards a viable solution...

I think you said it better than I did.  =8^) 

Taking a bit of a bent, here... Of course, from the (amd64) user side, 
the single missing feature I think of most often is missing full multi-
arch, not for me personally as I do source only, but there are a lot of 
folks that would certainly not miss having to do the chroot thing to get 
the full usual benefits of Gentoo -- the pre-compiled emul- packages are 
nice and definitely serve a purpose, but just aren't the same.  Do either 
of the alternatives deal with that?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Christopher Covington]

On 3/30/07, Mike Frysinger <vapier@gentoo.org> 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

[Andrej Kacian]

On Sat, 31 Mar 2007 20:02:28 +0200
"Christopher Covington" <covracer@gmail.com> 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

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 3168 bytes --]

On Sat, 2007-03-31 at 20:16 +0200, Andrej Kacian wrote:
> On Sat, 31 Mar 2007 20:02:28 +0200
> "Christopher Covington" <covracer@gmail.com> 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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Andrej Kacian]

On Sat, 31 Mar 2007 15:24:03 -0400
Seemant Kulleen <seemant@gentoo.org> 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

[Stephen Bennett]

On Sat, 31 Mar 2007 15:24:03 -0400
Seemant Kulleen <seemant@gentoo.org> 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

[gentoo-dev] Re: [soc] Python bindings for Paludis

[Steve Long]

Stephen Bennett wrote:
> On Sat, 31 Mar 2007 15:24:03 -0400
> Seemant Kulleen <seemant@gentoo.org> wrote:
>> To make it more clear...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?

Too late for all the affected users tho. Point is it's a major security hole
which no sane organisation would even consider for mission-critical code.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

On Sat, 31 Mar 2007 23:27:19 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Stephen Bennett wrote:
> > ... Gentoo developers can take the latest release of said package
> > manager and continue development from that. That's the wonderful
> > thing about the GPL, no?
> 
> Too late for all the affected users tho. Point is it's a major
> security hole which no sane organisation would even consider for
> mission-critical code.

Do you really think anyone checks every last line of code in every
release of every system package? Sneaking in a check
for /etc/gentoo-release with a time-delayed nasty into a widely used
package wouldn't be particularly hard for anyone serious... Heck,
getting oneself recruited under a pseudonym and sneaking some very
nasty global scope code into the tree wouldn't be particularly hard for
anyone serious...

These arguments are getting weaker and weaker...

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

On Saturday 31 March 2007, Ciaran McCreesh wrote:
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > Too late for all the affected users tho. Point is it's a major
> > security hole which no sane organisation would even consider for
> > mission-critical code.
>
> These arguments are getting weaker and weaker...

security based concerns in this sort of scenario can be turfed ... i dont 
think it's a relevant concern compared to the other issues at hand
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Alec Warner]

> On Sat, 31 Mar 2007 15:24:03 -0400
> Seemant Kulleen <seemant@gentoo.org> 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

[Mike Kelly]

[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[antarus]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On Tue, 03 Apr 2007 10:10:30 -0700
antarus <antarus@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Saturday 31 March 2007, Andrej Kacian wrote:
> "Christopher Covington" <covracer@gmail.com> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Michael Krelin]

>>> 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

[gentoo-dev] Re: [soc] Python bindings for Paludis

[Duncan]

Ciaran McCreesh <ciaranm@ciaranm.org> posted
20070325154636.5b75ddc1@snowflake, excerpted below, on  Sun, 25 Mar 2007
15:46:36 +0100:

> On Sun, 25 Mar 2007 10:40:51 -0400
> Mike Frysinger <vapier@gentoo.org> 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?

An equally likely meaning (and the one I read into it) is that it might 
benefit a particular segment of Gentoo users, but as it's not the 
currently default/official package manager, it'd be a relatively small 
segment, made proportionally even smaller by the fact that these bindings 
would at least in the near term impact an even smaller segment of /that/ 
segment.

A segment of an already minor segment (certainly currently, tho that 
/may/ eventually change), not likely to be something that can reasonably 
be characterized as benefiting Gentoo as a whole, at least in the near to 
medium term, and beyond that, well, things remain up for grabs.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [soc] Python bindings for Paludis

[Steve Long]

Duncan wrote:
> A segment of an already minor segment (certainly currently, tho that
> /may/ eventually change), not likely to be something that can reasonably
> be characterized as benefiting Gentoo as a whole, at least in the near to
> medium term, and beyond that, well, things remain up for grabs.
> 
Hear hear, although i do tend to agree with Mr Goodyear's assessment; if not
Gentoo, then who? And hasn't Paludis improved Gentoo's QA already?

At the end of the day, some poor student is going to volunteer to do this
because they find it interesting (if it were to go ahead.) In that case,
I'd peronsally say let them. But I don't know the ins and outs of the
Council's thinking obviously. And TBH you lot voted them in to make this
kind of call.

Why not let them?


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Alec Warner]

> Duncan wrote:
>> A segment of an already minor segment (certainly currently, tho that
>> /may/ eventually change), not likely to be something that can reasonably
>> be characterized as benefiting Gentoo as a whole, at least in the near
>> to
>> medium term, and beyond that, well, things remain up for grabs.
>>
> Hear hear, although i do tend to agree with Mr Goodyear's assessment; if
> not
> Gentoo, then who? And hasn't Paludis improved Gentoo's QA already?
>
> At the end of the day, some poor student is going to volunteer to do this
> because they find it interesting (if it were to go ahead.) In that case,
> I'd peronsally say let them. But I don't know the ins and outs of the
> Council's thinking obviously. And TBH you lot voted them in to make this
> kind of call.
>
> Why not let them?

Because IMHO it's not their place.  We have a Summer of Code Project.  We
know there are issues.  We plan to address them.  The council is the *last
place* to take issues in my mind.  Think Supreme Court (bad analogy but
whatever).  If you have a problem with the way the summer of code is
handling (or perhaps will handle) this situation feel free to talk to us,
e-mail us, find us on irc (gentoo-soc@gentoo.org and #gentoo-soc
respectively).

<rant>
I get really irritated when people just say 'well go talk to the council'
when they haven't even talked to the project members, or the project lead,
or god forbid, the ombudsman.
</rant>

-Alec

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Daniel Drake]

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

[Denis Dupeyron]

On 3/24/07, Daniel Drake <dsd@gentoo.org> 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

[Luca Barbato]

Piotr Jaroszyński wrote:
> Hello,
> 
> I have already submitted my application, but want to advertise it over here 
> too :] Comments are welcome!
> 
> Summary:
> Create Python bindings, associated documentation and test cases for the 
> Paludis public API, and allow subclassing of Paludis classes using Python.

Check my counterproposal. I know it is more broad but it also fits
better Gentoo as whole.

For the ones that aren't following gentoo-soc:

- C/C++/Ruby/python bindings/API for package managers.

The idea is to have some kind of common ground for applications willing
to use our wonderful package managers.

Task list:

- define a basic API for basic query and basic commands
- implement it for paludis/pkgcore/portage a non native language
- implement a little front-end using it (that would act as a subset of
emerge)
- extend the API to cover more features.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Ciaran McCreesh]

On Sat, 24 Mar 2007 08:09:09 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Check my counterproposal. I know it is more broad but it also fits
> better Gentoo as whole.
> 
> For the ones that aren't following gentoo-soc:
> 
> - C/C++/Ruby/python bindings/API for package managers.
> 
> The idea is to have some kind of common ground for applications
> willing to use our wonderful package managers.

Which is all very nice in theory, but completely impractical and
useless in practice. There's far too much difference and far too much
complexity implementation-wise to make this practical for any
non-trivial functionality.

-- 
Ciaran McCreesh

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[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.

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

[Danny van Dyk]

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 <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [soc] Python bindings for Paludis

[Luca Barbato]

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