Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Paludis and Profiles
Date: Thu, 18 May 2006 21:20:54
Message-Id: 20060518211003.GD3858@nightcrawler
In Reply to: Re: [gentoo-dev] Paludis and Profiles by Ciaran McCreesh
1 On Thu, May 18, 2006 at 09:58:02PM +0100, Ciaran McCreesh wrote:
2 > On Thu, 18 May 2006 22:39:20 +0200 Paul de Vrieze <pauldv@g.o>
3 > | > | What he is driving it at is that either paludis is an alternative
4 > | > | (yet on disk compatible) primary, or it's a secondary- you keep
5 > | > | debating the compatibility angle, thus the logical conclussion is
6 > | > | that it's a secondary.
7 > | >
8 > | > We're an alternative, not entirely on disc compatible primary.
9 > |
10 > | This means that you could choose to meet the requirements that I am
11 > | currently writing down in GLEP shape for package managers that desire
12 > | to replace portage as the primary package manager. Those requirements
13 > | can be met, but would limit the freedom choise of implementation of
14 > | the package manager.
15 >
16 > GLEPs are to *Enhance*, not to hold back.
17
18 Several of your gleps restrict the tree (rhetoric not withstanding)-
19 this is fundamentally no different, it's a restriction on what the is
20 required of a pkg manager for it to be a primary available in the
21 tree- this includes whatever profiles/mods it requires/wants.
22
23
24 > | > Design choice. We chose not to continue with previous design
25 > | > mistakes that exist only because of limitations in Portage's dep
26 > | > resolver where we can do so without requiring ebuild changes.
27 > |
28 > | This is a valid design choise. It does however mean that paludis
29 > | perhaps can not meet the requirements for being a replacement for
30 > | portage as gentoo primary package manager.
31 >
32 > You could come up with a requirement saying that "any replacement for
33 > Portage must have an 'o' in its name". Wouldn't make it a valid
34 > requirement. Fact is, Paludis can be used as and is being used as a
35 > primary package manager.
36
37 No one is disputing that. What they are disputing is whether paludis
38 has any place in the tree if it's not going to be ondisk (whether
39 profile, ebuild, or vdb) compatible with portage.
40
41 Say paludis *did* get into the tree, and the changes you've coded into
42 paludis already took hold- we would have a tree that is part paludis,
43 and part portage.
44
45 If it's not going to be compatible under guidelines council/approved
46 glep dictates, then it has no place in the tree.
47
48 Aside from that, lay off the smart ass "any replacement for portage
49 must have an 'o' in its name" crap- folks aren't going to budge on
50 this one, so just address the points they're raising rather then
51 dodging it (thus requiring another email from 'em dragging the answer
52 out of you).
53
54 ~harring