[gentoo-dev] Paludis and Profiles

[gentoo-dev] Paludis and Profiles

[Stephen Bennett]

If noone has any strong reasonable objections, I'd like to add a
Paludis profile to the tree. This would use Paludis as the default
provider for virtual/portage (which is a less than ideal name, but that
is another discussion entirely), and provide ebuild devs with a place
where they can try out some of our profile enhancements should they
want to. It is worth noting on the last point that most of these are
long-standing Portage feature requests, at least some of which are
planned for inclusion in Portage at some point in the future. This
would allow devs access to them earlier, as a sort of testbed.

The next question is where to put it. The options as I see them are
under default-linux/x86/ or in a top-level paludis/ a la hardened,
selinux, embedded, and the like. The latter is easier to exclude for
those worried about tree size, though the impact there should be
minimal. Neither way produces significantly more duplication, since we
can make use of multiple profile inheritance. If anyone has any
preference or other input, I'd like to hear it.

That's my proposal. The benefits I like to think are obvious. The
drawbacks are, as far as I can see, in tree size, which should be
minimal. Those concerned about local tree size can exclude it, and for
size on the mirrors it's trivial compared to the rest of the tree.

Comments?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Thomas Cort]

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

On Tue, 16 May 2006 16:15:49 +0100
Stephen Bennett <spb@gentoo.org> wrote:
> The next question is where to put it. The options as I see them are
> under default-linux/x86/ or in a top-level paludis/ a la hardened,
> selinux, embedded, and the like. The latter is easier to exclude for
> those worried about tree size, though the impact there should be
> minimal. Neither way produces significantly more duplication, since we
> can make use of multiple profile inheritance. If anyone has any
> preference or other input, I'd like to hear it.

I don't understand the logic behind putting it under default-linux/x86/. Is palidus Linux/x86 only? Could you explain why default-linux/x86/ is a good option?

-- 
,__,       +----------+  |  Thomas Cort <tcort@gentoo.org>
(oo)____   |SAVE LARRY|  |  Gentoo Linux Developer
(__)    )\ +----------+  |  alpha, amd64, sound
   ||--|| *      |       |  http://dev.gentoo.org/~tcort


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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

Thomas Cort wrote:
> I don't understand the logic behind putting it under default-linux/x86/.
 > Is palidus Linux/x86 only? Could you explain why default-linux/x86/ 
is a good option?

It's not -- it's currently confirmed to work on x86, amd64, sparc, mips, 
   alpha, and hppa. I don't believe it is a good option, but some people 
may object less to a profile hidden away there than one at the top 
level. *shrug*
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Tue, May 16, 2006 at 04:15:49PM +0100, Stephen Bennett wrote:
> If noone has any strong reasonable objections, I'd like to add a
> Paludis profile to the tree. This would use Paludis as the default
> provider for virtual/portage (which is a less than ideal name, but that
> is another discussion entirely), and provide ebuild devs with a place
> where they can try out some of our profile enhancements should they
> want to. It is worth noting on the last point that most of these are

> Comments?

Maybe I'm daft, but why does this need to be demoed in the live tree?  
Use an overlay (y'all have one already anyways).  Reasons why this is 
a bit daft-

1) changes to the eapi=0 ebuild standard; renaming of vars 
(PORTAGE_* -> PALUDIS_* namely), dropping of all local vars during 
phase changes (since y'all lack ebuild, it'll rear it's head mainly 
during unmerge), effective dropping of config phase (another place 
it would rear it's head)... Mind you that's from a quick read through 
of your ebuild env reimplementation, stated the issues already and 
they still remain- incomplete support for the standard is one thing, 
changing it is another (y'all are doing the latter).

2) N profile inheritance- the parents change (N entries instead of 
one) needs to be protected so that specific profile is only usable by 
a package manager (whether portage, pkgcore or paludis) that actually 
does N parent inheritance.  This is why N profile inheritance has 
never been added to portage (it's honestly a one line change in 
portage)- the change must not be introduced without protection, 
else the user's system set can become drastically reduced.  It's not 
an easily addressable problem (all solutions sans a new profile 
directory leave open the potential for users to get bit), ignoring it 
is a no go.  Yes, you're after demoing capabilities- problem is that 
it's exposing potential horkage in a production tree, wrong place to 
be demoing.

3) vdb CONTENTS change of dev/fif to misc.  It's dumb, but that change 
renders vdb entries incompatible- iow, proper usage/conversion to 
paludis requires a new installation (or translation script, both 
to/from portage).

So... short version, introduction of the profile allows for curious 
users to get bit in the ass by intentional dropping of compatibility 
(profile level changes are one thing, changing the ebuild standard is 
another).  In light of that, why should it be demoed in the tree where 
the only use of it is to bootstrap a new installation?  Just overlay 
it, y'all should be maintaining an overlay fixing ebuild incompatibilities 
anyways.

> That's my proposal. The benefits I like to think are obvious. The
> drawbacks are, as far as I can see, in tree size, which should be
> minimal.

Benefits of demo'ing for a minority (300 devs) must be balanced 
against risk (adding profiles that portage can eat itself on, the 
default virtual change doesn't address it, eapi incompatibility, vdb 
changes )- wrong place to be deploying incompatibilites that paludis 
introduces is into the production tree without appropriate 
containment/protection.

The gain of the profile is that you can do a few new tricks for folks 
doing boostrapping experiments- why not just introduce an ebuild that 
sets up the new profile in a temp overlay?

Still have the sandbox for experimenting/demoing, but it minimizes the 
potential borkage folks can hit by doing stupid things.

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 09:16:18 -0700 Brian Harring <ferringb@gmail.com>
wrote:
| 1) changes to the eapi=0 ebuild standard; renaming of vars 
| (PORTAGE_* -> PALUDIS_* namely)

What eapi=0 standard? We emulate Portage internals where it's found to
be necessary, and don't otherwise.

| dropping of all local vars during phase changes

Again, we emulate Portage misfeatures only where it's found to be
necessary.

| effective dropping of config phase

Uh, no. Config's on the 0.4 list. We're just prioritising things that
we actually need.

| Mind you that's from a quick read through 
| of your ebuild env reimplementation, stated the issues already and 
| they still remain- incomplete support for the standard is one thing, 
| changing it is another (y'all are doing the latter).

What standard? Are you trying to say that Paludis should emulate
Portage's bugs, because the standard is "exactly what Portage does"?

| 2) N profile inheritance- the parents change (N entries instead of 
| one) needs to be protected so that specific profile is only usable by 
| a package manager (whether portage, pkgcore or paludis) that actually 
| does N parent inheritance.  This is why N profile inheritance has 
| never been added to portage (it's honestly a one line change in 
| portage)- the change must not be introduced without protection, 
| else the user's system set can become drastically reduced.  It's not 
| an easily addressable problem (all solutions sans a new profile 
| directory leave open the potential for users to get bit), ignoring it 
| is a no go.  

Uh, no. Any user who isn't using a package manager capable of multiple
inherits shouldn't use a multiple inherits profile. There's plenty of
precedent of intro

| Yes, you're after demoing capabilities- problem is that 
| it's exposing potential horkage in a production tree, wrong place to 
| be demoing.

Heh. "potential horkage". Yes, if a user sets their profile
incorrectly, things break. That's the case currently too. 

| 3) vdb CONTENTS change of dev/fif to misc.  It's dumb, but that
| change renders vdb entries incompatible- iow, proper usage/conversion
| to paludis requires a new installation (or translation script, both 
| to/from portage).

Had you bothered to read the documentation, you'd know that we don't
claim nor desire VDB compatibility with Portage, and don't encourage
installs onto the same ROOT.

We also don't emulate Portage's broken handling of merging directories
onto symlinks, which means that uninstalling via emerge sometimes
leaves behind cruft.

| So... short version, introduction of the profile allows for curious 
| users to get bit in the ass by intentional dropping of compatibility 
| (profile level changes are one thing, changing the ebuild standard is 
| another).  In light of that, why should it be demoed in the tree
| where the only use of it is to bootstrap a new installation?  Just
| overlay it, y'all should be maintaining an overlay fixing ebuild
| incompatibilities anyways.

Because Paludis is now a viable alternative to Portage and can be used
to install and maintain a real system. We already support enough of the
"ebuild standard" and emulate enough of Portage's bugs to install
system + X + KDE + Gnome + a whole load of random stuff that people
actually use.

| > That's my proposal. The benefits I like to think are obvious. The
| > drawbacks are, as far as I can see, in tree size, which should be
| > minimal.
| 
| Benefits of demo'ing for a minority (300 devs) must be balanced 
| against risk (adding profiles that portage can eat itself on, the 
| default virtual change doesn't address it

Uh, a user changing to any incorrect profile will screw up their
system. Ever tried using an amd64 profile on x86?

| eapi incompatibility

You mean "not emulating some of Portage's sillier bugs that very few
things rely upon anyway", right?

| vdb changes )- wrong place to be deploying incompatibilites that paludis 
| introduces is into the production tree without appropriate 
| containment/protection.

Uh, VDB isn't part of the tree. Nor does it introduce any breakages for
existing users, except those who do something especially dumb. Even if
a user *does* change their profile to a Paludis profile, it won't cause
Portage to explode in such a way that switching profiles back won't fix
it.

| The gain of the profile is that you can do a few new tricks for folks 
| doing boostrapping experiments- why not just introduce an ebuild that 
| sets up the new profile in a temp overlay?

No, the gain of the profile is that it prepares the way for people to
move onto a package manager that doesn't suck.

Now, if you were to object to, say, -scm versions in the main tree,
whose very existence causes Portage to crap itself messily and die, you
might have a point. But adding a profile only screws things up for
users who manually switch to it, and it only screws them up temporarily
and fairly cleanly.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Alec Warner]

Ciaran McCreesh wrote:
> On Tue, 16 May 2006 09:16:18 -0700 Brian Harring <ferringb@gmail.com>
> wrote: 
> | vdb changes )- wrong place to be deploying incompatibilites that paludis 
> | introduces is into the production tree without appropriate 
> | containment/protection.
> 
> Uh, VDB isn't part of the tree. Nor does it introduce any breakages for
> existing users, except those who do something especially dumb. Even if
> a user *does* change their profile to a Paludis profile, it won't cause
> Portage to explode in such a way that switching profiles back won't fix
> it.
> 

I would prefer to see the profile you are commiting then; do you have a 
link?

-Alec Warner

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

Alec Warner wrote:
> I would prefer to see the profile you are commiting then; do you have a 
> link?

I haven't written it yet.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Paludis and Profiles

[Duncan]

Stephen Bennett <spb@gentoo.org> posted 448EF724.8010709@gentoo.org,
excerpted below, on  Tue, 16 May 2006 17:41:24 +0000:

> Alec Warner wrote:
>> I would prefer to see the profile you are commiting then; do you have a 
>> link?
> 
> I haven't written it yet.

Herein lies the crux of the problem, IMO.  Regardless of all the other
arguments made, I simply cannot believe it is reasonable to ask that
Gentoo devs give their blessing to add to the tree something that hasn't
yet even been written, let alone tested not to break anything with
existing portage.

I /am/ a bit skeptical that the solution as proposed would cause the sorts
of breakage some people seem to think it will.  I /am/ cautiously
supportive of the proposal as outlined, provided it has been reasonably
tested as as an overlay or locally imposed tree structure, and that there
is a way for devs to independently test it themselves, but this?  It's not
written yet, yet devs are being asked to support its addition live tree,
sight unseen, upon some description of a proposal of what it /might/ look
like?

Someone requested a patch, here worded as an overlay request, that devs
(and users who want to risk their necks <g> I'd strongly suggest
verifying the backups are updated and testing them previous to trying it)
could try, before a yeah or nay is given to the act of actually adding it
to the tree.  I believe that to be a reasonable request.

Meanwhile, and possibly eliminating the need for the separate profiles,
the virtual/portage idea seems worthy of consideration, as others have
pointed out, quite independent of what other choices are eventually
offered.  pkgcore or something else could find it equally helpful, and it
won't hurt to build in that flexibility now.

-- 
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: Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 16:28:21 +0000 (UTC)
"Duncan" <1i5t5.duncan@cox.net> wrote:

> Herein lies the crux of the problem, IMO.  Regardless of all the other
> arguments made, I simply cannot believe it is reasonable to ask that
> Gentoo devs give their blessing to add to the tree something that
> hasn't yet even been written, let alone tested not to break anything
> with existing portage.

The initial request was for any objections to the principle. Since
people asked for a concrete example of what was going in, I provided it.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Paludis and Profiles

[Duncan]

Stephen Bennett <spb@gentoo.org> posted 20060517175622.6e685699@localhost,
excerpted below, on  Wed, 17 May 2006 17:56:22 +0100:

> On Wed, 17 May 2006 16:28:21 +0000 (UTC) "Duncan" <1i5t5.duncan@cox.net>
> wrote:
> 
>> Herein lies the crux of the problem, IMO.  Regardless of all the other
>> arguments made, I simply cannot believe it is reasonable to ask that
>> Gentoo devs give their blessing to add to the tree something that hasn't
>> yet even been written, let alone tested not to break anything with
>> existing portage.
> 
> The initial request was for any objections to the principle. Since people
> asked for a concrete example of what was going in, I provided it.

Point made.  I guess I have a different view of the order things would go
in, tho.  I'd have the overlay and have tested it, so I could make a
concrete statement that it didn't affect portage except if someone chose
the wrong profile (and could defend the reversibility of that mistake
claim based on real tests, if I were to make it), before even /asking/ for
tree changes.

Anyway, the discussion is going on, now, so too late for what might have
been.

Someone will no doubt tell me to go put it on my blog, but...  it seems
appropriate. Sometimes I feel like Rodney King have felt, when he asked..
"Can't we all just get along?"  =8^) I know it's a bit idealistic to think
that way, but...  I just see so many folks blowing small things so out of
proportion, and so little effort being made to see the situation from the
other guy's perspective, before the reply. =8^(  It just seems such things
cost needless stress at the minimum, lost hours and less smooth operations
in many cases, and the loss of valuable developers and possibly forks, at
the extreme end.  OTOH, it's obviously not just Gentoo with such issues,
as there are cases in point littering both the FLOSS and closed source
communities.  (Of course, the FLOSS community ones tend to be more
publicly visible.)

Bringing that back home... trying to see both viewpoint here, it seems to
me the logical next step is that proof of concept overlay or whatever one
wishes to call it.  One way or another, it's needed, whether or not it's
ultimately allowed in the tree as a profile, so getting it done and
getting the debate onto concrete terms would seem useful.  If it's decided
not to have it in the tree at this time, then the work can continue to be
used as an overlay.

-- 
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: Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 18:56, Stephen Bennett wrote:
> On Wed, 17 May 2006 16:28:21 +0000 (UTC)
>
> "Duncan" <1i5t5.duncan@cox.net> wrote:
> > Herein lies the crux of the problem, IMO.  Regardless of all the other
> > arguments made, I simply cannot believe it is reasonable to ask that
> > Gentoo devs give their blessing to add to the tree something that
> > hasn't yet even been written, let alone tested not to break anything
> > with existing portage.
>
> The initial request was for any objections to the principle. Since
> people asked for a concrete example of what was going in, I provided it.

This request was such as to judge the advantages of adding it to the tree. 
This would allow judgement and weighing of the advantages and disadvantages.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Tue, May 16, 2006 at 05:47:42PM +0100, Ciaran McCreesh wrote:
> On Tue, 16 May 2006 09:16:18 -0700 Brian Harring <ferringb@gmail.com>
> wrote:
> | 1) changes to the eapi=0 ebuild standard; renaming of vars 
> | (PORTAGE_* -> PALUDIS_* namely)
> 
> What eapi=0 standard? We emulate Portage internals where it's found to
> be necessary, and don't otherwise.

eapi=0 is what 2.1/2.05x supports.

Features are fine, but for gentoo backwards compatibility *is* a 
concern, as such dropping the bits that you dislike (but existing 
ebuilds rely on) is a no go.

> | dropping of all local vars during phase changes
> 
> Again, we emulate Portage misfeatures only where it's found to be
> necessary.
See above...

> | Mind you that's from a quick read through 
> | of your ebuild env reimplementation, stated the issues already and 
> | they still remain- incomplete support for the standard is one thing, 
> | changing it is another (y'all are doing the latter).
> 
> What standard? Are you trying to say that Paludis should emulate
> Portage's bugs, because the standard is "exactly what Portage does"?

See above.  Paludis (my view) is a rewrite of portage, rather then a 
reimplementation- as you've stated, dropping the stuff that you deem 
misfeatures.

This is fine, but portage *is* what gentoo is based uses now, and 
what all ebuilds have been written to, as such you need to either 
support the misfeatures or have a bullet proof transition plan to deal 
with the things you decided to carve out.

This is directly relevant because you now want to modify the 
gentoo-x86 repo to standards gentoo does not actually support.  Call 
it "dropping the misfeatures", but it's the reality of backwards 
compatibility (something that has been kicking portage devs in the 
nuts for years now).


> | 2) N profile inheritance- the parents change (N entries instead of 
> | one) needs to be protected so that specific profile is only usable by 
> | a package manager (whether portage, pkgcore or paludis) that actually 
> | does N parent inheritance.  This is why N profile inheritance has 
> | never been added to portage (it's honestly a one line change in 
> | portage)- the change must not be introduced without protection, 
> | else the user's system set can become drastically reduced.  It's not 
> | an easily addressable problem (all solutions sans a new profile 
> | directory leave open the potential for users to get bit), ignoring it 
> | is a no go.  
> 
> Uh, no. Any user who isn't using a package manager capable of multiple
> inherits shouldn't use a multiple inherits profile. There's plenty of
> precedent of intro

Feature introduction is done via introducing support, then sitting on 
it for ~6 months to ensure folks don't get bit by it- notable 
exception was virtuals/* metapkg, although the buttload of bugs from 
it is a demonstration of *why* this route must be taken.

This is also why eapi came about- faster introduction of compatibility 
breaking changes.

Meanwhile, the precedent for changes to the tree (pkg manager related 
changes) is that of "don't break shit for users", introducing N parent 
inherit profiles into the tree still qualifies as a concern- as 
stated, you're after demoing capabilities, do it somewhere other then 
production data.


> | 3) vdb CONTENTS change of dev/fif to misc.  It's dumb, but that
> | change renders vdb entries incompatible- iow, proper usage/conversion
> | to paludis requires a new installation (or translation script, both 
> | to/from portage).
> 
> Had you bothered to read the documentation, you'd know that we don't
> claim nor desire VDB compatibility with Portage, and don't encourage
> installs onto the same ROOT.

Snarky response aside, I read the src (note the env screwups I've 
pointed out, and the fact y'all don't support try eclass unified 
overlays), and your documentation- the point was that paludis can 
only be used for new installs, and you're locked to paludis as your 
pkg manager at that point without a translation script.

Trying to make it clear that paludis isn't something you try out for a 
bit, then revert back to portage- it's a full rebuild.  That seriously 
limits the usefulness of the requested profile.


> Because Paludis is now a viable alternative to Portage and can be used
> to install and maintain a real system. We already support enough of the
> "ebuild standard" and emulate enough of Portage's bugs to install

Just because something is a viable alternative to portage doesn't 
mean the tree should be mutated to the alternative, especially when 
the alternative breaks standards that are in the tree already.

Call it "misfeatures of portage", reality is that y'all introduce one 
insidious potential for bugs in 22k ebuilds via the env changes.

Yes, paludis is a viable pkg manager- it's not viable to work with 
ebuilds written to portage (eapi=0) however because of those adhoc 
changes, at least for the userbase size gentoo currently sports.  If 
it were breaks affecting 100 folk, hey, shit happens, but it's not.

One thing I am curious about though, is how closely you've checked 
things are running properly- ebuilds have preserved their state in 
local vars saved in the env dump for well over 2 years, cutting that 
out on a whim for 22k ebuilds is kind of risky.  It'll show at unmerge 
time and for binpkgs...


> | > That's my proposal. The benefits I like to think are obvious. The
> | > drawbacks are, as far as I can see, in tree size, which should be
> | > minimal.
> | 
> | Benefits of demo'ing for a minority (300 devs) must be balanced 
> | against risk (adding profiles that portage can eat itself on, the 
> | default virtual change doesn't address it
> 
> Uh, a user changing to any incorrect profile will screw up their
> system. Ever tried using an amd64 profile on x86?

We can't do anything about that idiocy.

That doesn't mean a profile should be added to the tree that portage 
is incapable of resolving properly however- simple example would be 
inheriting from two parents, one that's base arch agnostic defaults, 
other is arch specific modifications.

If that profile were used by portage, it would pick up *strictly* the 
base arch agnostic defaults- this isn't "you're using the wrong 
profile dumb ass", this is "only the left most path is actually 
recursed".  Again, this is why N profile inheritance isn't in portage- 
you cannot introduce it without backwards compatibility protection.  
Having the profile in the tree is an uneeded potential for bugs, yes 
it's obvious to a gentoo dev in seeing it when a bug is reported, but 
how many users know about the leftmost descent issue for portage?


> | eapi incompatibility
> 
> You mean "not emulating some of Portage's sillier bugs that very few
> things rely upon anyway", right?

See above.  Renaming of PORTAGE_* -> PALUDIS_* vars doesn't strike me 
as "sillier bugs", strikes me as "we stamped it with our name, thus 
introducing subtle bugs into minor packages like perl".

And yes, that's actually a valid example- easy to spot via just a 
simple grepping of the tree (I suggest you do so).


> | vdb changes )- wrong place to be deploying incompatibilites that paludis 
> | introduces is into the production tree without appropriate 
> | containment/protection.
> 
> Uh, VDB isn't part of the tree. Nor does it introduce any breakages for
> existing users, except those who do something especially dumb. Even if
> a user *does* change their profile to a Paludis profile, it won't cause
> Portage to explode in such a way that switching profiles back won't fix
> it.

Point is, the tree (you're own words) is not a playground, nor is it a 
demoscene- don't introduce the potential for screwup in the tree 
without a damn good reason.

Demo'ing capabilities doesn't qualify, do it in the overlay y'all 
have.


> | The gain of the profile is that you can do a few new tricks for folks 
> | doing boostrapping experiments- why not just introduce an ebuild that 
> | sets up the new profile in a temp overlay?
> 
> No, the gain of the profile is that it prepares the way for people to
> move onto a package manager that doesn't suck.

Figured as much, the problem is that you cannot convert a communal 
resource (gentoo-x86) to be paludis specific without the go ahead from 
the rest of the community.  The tree must not be changed ad hoc to 
match whatever pkg manager the commiter likes (this includes pkgcore).  
Standards...

Bluntly, you break compatibility with vdb/tree, paludis has no real 
future with gentoo beyond forking- requiring 100,000 users to 
reinstall because you don't want to do backwards compatibility is 
daft.

The original discussion was about adding a paludis profile (not 
"portage sucks"), getting back to it, paludis is incompatible with 
portage at the actual ebuild level- considering that, why should the 
tree be modified to add a profile that's just going to introduce 
further breakage?

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 10:33:56 -0700 Brian Harring <ferringb@gmail.com>
wrote:
| > What eapi=0 standard? We emulate Portage internals where it's found
| > to be necessary, and don't otherwise.
| 
| eapi=0 is what 2.1/2.05x supports.

That's not really true. Relying upon "anything that Portage handles",
including relying upon Portage bugs and internals, leads to broken
ebuilds when said things change.

| Features are fine, but for gentoo backwards compatibility *is* a 
| concern, as such dropping the bits that you dislike (but existing 
| ebuilds rely on) is a no go.

You're acting like Paludis is dropping something huge here. Not
emulating a few weird PORTAGE_ variables that nothing uses is not
breaking eapi. If ebuilds genuinely rely upon something, we emulate as
necessary.

| > | Mind you that's from a quick read through 
| > | of your ebuild env reimplementation, stated the issues already
| > | and they still remain- incomplete support for the standard is one
| > | thing, changing it is another (y'all are doing the latter).
| > 
| > What standard? Are you trying to say that Paludis should emulate
| > Portage's bugs, because the standard is "exactly what Portage does"?
| 
| See above.  Paludis (my view) is a rewrite of portage, rather then a 
| reimplementation- as you've stated, dropping the stuff that you deem 
| misfeatures.

A 'rewrite' implies that we're starting from "what Portage does", and
making something that does the same thing in the same way. That's not
how it's being done. We're looking at it a) from what ebuilds do, and
b) from what the program is expected to do, and then filling in the
middle. The only part that's really at all close to Portage is the bash
stuff for ebuilds, and that's pretty much necessary because of the
ebuild <-> package manager interface thing.

*shrug* Your perception on this one's probably skewed if (as it seems)
you've been focusing on the trivial and easily replaceable bash part,
rather than the interesting things which are done in C++.

| This is fine, but portage *is* what gentoo is based uses now, and 
| what all ebuilds have been written to, as such you need to either 
| support the misfeatures or have a bullet proof transition plan to
| deal with the things you decided to carve out.

Which, funnily enough, is what we do.

| This is directly relevant because you now want to modify the 
| gentoo-x86 repo to standards gentoo does not actually support.  Call 
| it "dropping the misfeatures", but it's the reality of backwards 
| compatibility (something that has been kicking portage devs in the 
| nuts for years now).

Again, not really true. Said Portage devs have pushed through far
larger changes than anything we need -- look at the "use becoming useq"
behaviour changes, for example. Paludis does not require or want any
such large change, and we'd consider anything that required that to be
broken.

| Feature introduction is done via introducing support, then sitting on 
| it for ~6 months to ensure folks don't get bit by it- notable 
| exception was virtuals/* metapkg, although the buttload of bugs from 
| it is a demonstration of *why* this route must be taken.

There is a difference between "changes that affect people not using the
newer package manager" and "changes that are only relevant to people
using the newer package manager". Anyone asking for features that will
lead to Portage breaking will be beaten with a spork.

| This is also why eapi came about- faster introduction of
| compatibility breaking changes.

Which, unfortunately, it doesn't really do, since ebuilds still have to
be filename and source compatible. There were far better ways this
could have been handled.

| Meanwhile, the precedent for changes to the tree (pkg manager related 
| changes) is that of "don't break shit for users", introducing N
| parent inherit profiles into the tree still qualifies as a concern-
| as stated, you're after demoing capabilities, do it somewhere other
| then production data.

N parent inherit profiles don't break anything for users who don't use
said profiles. Any user switching to an unsuitable profile, N parent or
not, will end up with a h0rked system. The same occurs when new
profiles requiring newer Portage versions are introduced, and that's
been done several times.

| Snarky response aside, I read the src (note the env screwups I've 
| pointed out, and the fact y'all don't support try eclass unified 
| overlays), and your documentation- the point was that paludis can 
| only be used for new installs, and you're locked to paludis as your 
| pkg manager at that point without a translation script.

Had you read the source or the documentation, you'd know fine well that
we support eclass unified overlays. I really think you should refrain
from making those kinds of claims until you actually have the slightest
clue what you're talking about.

| Trying to make it clear that paludis isn't something you try out for
| a bit, then revert back to portage- it's a full rebuild.  That
| seriously limits the usefulness of the requested profile.

Sure. Which is why it's a profile scope thing, the same as, say,
multilib.

| Just because something is a viable alternative to portage doesn't 
| mean the tree should be mutated to the alternative

Adding a subprofile is not mutating the tree. Get a sense of
perspective here. We're not asking everyone to change how they invoke
the 'use' function...

| Yes, paludis is a viable pkg manager- it's not viable to work with 
| ebuilds written to portage (eapi=0) however

Sure it is.

| One thing I am curious about though, is how closely you've checked 
| things are running properly- ebuilds have preserved their state in 
| local vars saved in the env dump for well over 2 years, cutting that 
| out on a whim for 22k ebuilds is kind of risky.  It'll show at
| unmerge time and for binpkgs...

Funnily enough, we know what we're doing.

| > Uh, a user changing to any incorrect profile will screw up their
| > system. Ever tried using an amd64 profile on x86?
| 
| We can't do anything about that idiocy.
| 
| That doesn't mean a profile should be added to the tree that portage 
| is incapable of resolving properly however- simple example would be 
| inheriting from two parents, one that's base arch agnostic defaults, 
| other is arch specific modifications.

Huh? Profiles that some Portage versions can't use have been added
plenty of times previously.

| > | eapi incompatibility
| > 
| > You mean "not emulating some of Portage's sillier bugs that very few
| > things rely upon anyway", right?
| 
| See above.  Renaming of PORTAGE_* -> PALUDIS_* vars doesn't strike me 
| as "sillier bugs", strikes me as "we stamped it with our name, thus 
| introducing subtle bugs into minor packages like perl".

We emulate some PORTAGE_ variables. We don't emulate the ones that
aren't necessary.

| And yes, that's actually a valid example- easy to spot via just a 
| simple grepping of the tree (I suggest you do so).

Heh. You lose. It isn't.

| Point is, the tree (you're own words) is not a playground, nor is it
| a demoscene- don't introduce the potential for screwup in the tree 
| without a damn good reason.

That argument is like claiming that adding an amd64 profile to the tree
is a potential screwup because x86 users might use it.

| Bluntly, you break compatibility with vdb/tree, paludis has no real 
| future with gentoo beyond forking- requiring 100,000 users to 
| reinstall because you don't want to do backwards compatibility is 
| daft.

A reinstall isn't needed at all.

| The original discussion was about adding a paludis profile (not 
| "portage sucks"), getting back to it, paludis is incompatible with 
| portage at the actual ebuild level- considering that, why should the 
| tree be modified to add a profile that's just going to introduce 
| further breakage?

Paludis is no more incompatible with ebuilds than any new Portage
release is.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Grant Goodyear]

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

Ciaran McCreesh wrote: [Tue May 16 2006, 01:07:05PM CDT]
> | Bluntly, you break compatibility with vdb/tree, paludis has no real 
> | future with gentoo beyond forking- requiring 100,000 users to 
> | reinstall because you don't want to do backwards compatibility is 
> | daft.
> 
> A reinstall isn't needed at all.

Just to clarify my own poor understanding, if somebody builds a box
using paludis and then decides that she'd really prefer to use portage
instead, isn't that going to require a reinstall (at least until there's
a program that takes a paludis installed-package database and can
generate the equivalent portage db)?

-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] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 13:23:18 -0500 Grant Goodyear <g2boojum@gentoo.org>
wrote:
| Just to clarify my own poor understanding, if somebody builds a box
| using paludis and then decides that she'd really prefer to use portage
| instead, isn't that going to require a reinstall (at least until
| there's a program that takes a paludis installed-package database and
| can generate the equivalent portage db)?

Yeah. Paludis -> Portage is losing features, so the conversion won't
work that way. Portage -> Paludis is sort of doable currently, and can
be made to work if it's considered important (which it will be, at some
point in the future).

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Tue, May 16, 2006 at 07:07:05PM +0100, Ciaran McCreesh wrote:
> On Tue, 16 May 2006 10:33:56 -0700 Brian Harring <ferringb@gmail.com>
> wrote:
> | > What eapi=0 standard? We emulate Portage internals where it's found
> | > to be necessary, and don't otherwise.
> | 
> | eapi=0 is what 2.1/2.05x supports.
> 
> That's not really true. Relying upon "anything that Portage handles",
> including relying upon Portage bugs and internals, leads to broken
> ebuilds when said things change.

...which is why the ebuild env for portage is extremely carefully 
maintained- mistakes may occur, but willy nilly changes don't.  
Regardless, at least for gentoo it still however *is* the standard 
for ebuilds, breaking the 'standard' out of portage is fine, changing 
intrinsic parts of the standard isn't.


> | Features are fine, but for gentoo backwards compatibility *is* a 
> | concern, as such dropping the bits that you dislike (but existing 
> | ebuilds rely on) is a no go.
> 
> You're acting like Paludis is dropping something huge here. Not
> emulating a few weird PORTAGE_ variables that nothing uses is not
> breaking eapi. If ebuilds genuinely rely upon something, we emulate as
> necessary.

Then I'll state it again; you're changing the core environment 
handling via intentionally dropping all local vars defined per phase 
run.  Add binpkgs, and try it- you'll get some fun behaviour there.


> A 'rewrite' implies that we're starting from "what Portage does", and
> making something that does the same thing in the same way. That's not
> how it's being done. We're looking at it a) from what ebuilds do, and
> b) from what the program is expected to do, and then filling in the
> middle. The only part that's really at all close to Portage is the bash
> stuff for ebuilds, and that's pretty much necessary because of the
> ebuild <-> package manager interface thing.
> 
> *shrug* Your perception on this one's probably skewed if (as it seems)
> you've been focusing on the trivial and easily replaceable bash part,
> rather than the interesting things which are done in C++.

The bash part is all that matters, hence why I'm focusing on it- as 
you stated above, the data (ebuilds) handling is what matters.  

Stating that the bash concerns are trivial while the C++ side can be 
interesting is ignoring the point, the bash bits must match- I don't 
care if it's C++ or python or haskell for the high level, the ebuild 
env support must *not* induce any intentional changes that break 
ebuilds.


> Again, not really true. Said Portage devs have pushed through far
> larger changes than anything we need -- look at the "use becoming useq"
> behaviour changes, for example. Paludis does not require or want any
> such large change, and we'd consider anything that required that to be
> broken.

use/useq change over occured well after the tree had been converted- 
it's actually a decent example of how to do the changeover- that was 
also a permenant change, not a "paludis is an alternative and we want 
to stick it in the tree".


> | Feature introduction is done via introducing support, then sitting on 
> | it for ~6 months to ensure folks don't get bit by it- notable 
> | exception was virtuals/* metapkg, although the buttload of bugs from 
> | it is a demonstration of *why* this route must be taken.
> 
> There is a difference between "changes that affect people not using the
> newer package manager" and "changes that are only relevant to people
> using the newer package manager". Anyone asking for features that will
> lead to Portage breaking will be beaten with a spork.

N profile inheritance breaks portage.
You were saying?

Yes it's needed (regardless of the manager), but the point was "don't 
expose users to sharp/pointy things without a good reason".


> | This is also why eapi came about- faster introduction of
> | compatibility breaking changes.
> 
> Which, unfortunately, it doesn't really do, since ebuilds still have to
> be filename and source compatible. There were far better ways this
> could have been handled.

Feel free to suggest them- since it's initial discussion, your 
comments on it haven't really progressed beyond "y'all did it badly", 
without naming a solution that works.

EAPI has it's faults, but it *does* version the ebuild format 
(regardless of the tree format) to move forward, which was it's 
intention.  Versioning the tree format is a related, but seperate 
issue.


> | Snarky response aside, I read the src (note the env screwups I've 
> | pointed out, and the fact y'all don't support try eclass unified 
> | overlays), and your documentation- the point was that paludis can 
> | only be used for new installs, and you're locked to paludis as your 
> | pkg manager at that point without a translation script.
> 
> Had you read the source or the documentation, you'd know fine well that
> we support eclass unified overlays. I really think you should refrain
> from making those kinds of claims until you actually have the slightest
> clue what you're talking about.

Offhand, you're ignoring the point about lack of translation script 
for vdb, and that paludis requires a new install.

Re: eclass, had to dig in the src for that one, doc's don't cover it.  
Your repositories support specifying an arbitrary eclass- they do not 
support the standard unification on the fly of eclass that most 
portage users use- *technically* it can be done via copying eclasses 
from each repo into an eclass directory (better yet symlinks), but 
that's not unifying- that's working around the implementation.

Simple example, eclasses in overlay X must override PORTDIR y, no 
eclass in X, check Y.

If paludis supports that common usage model, kindly point it out 
since I've yet to spot support in the code for it.


> | > Uh, a user changing to any incorrect profile will screw up their
> | > system. Ever tried using an amd64 profile on x86?
> | 
> | We can't do anything about that idiocy.
> | 
> | That doesn't mean a profile should be added to the tree that portage 
> | is incapable of resolving properly however- simple example would be 
> | inheriting from two parents, one that's base arch agnostic defaults, 
> | other is arch specific modifications.
> 
> Huh? Profiles that some Portage versions can't use have been added
> plenty of times previously.

Yep, and we still get bugs about .50- that doesn't mean it's right 
(just because someone else did something stupid doesn't mean you can). 
It's pretty simple, don't stick stuff into the tree that can silently 
fail, stick stuff in that is detected instead of silent failures.


> | See above.  Renaming of PORTAGE_* -> PALUDIS_* vars doesn't strike me 
> | as "sillier bugs", strikes me as "we stamped it with our name, thus 
> | introducing subtle bugs into minor packages like perl".
> 
> We emulate some PORTAGE_ variables. We don't emulate the ones that
> aren't necessary.
> 
> | And yes, that's actually a valid example- easy to spot via just a 
> | simple grepping of the tree (I suggest you do so).
> 
> Heh. You lose. It isn't.

look in the files directory- specifically modifies extmaker to be 
PORTAGE_TMPDIR aware to fix a security bug.


> | Point is, the tree (you're own words) is not a playground, nor is it
> | a demoscene- don't introduce the potential for screwup in the tree 
> | without a damn good reason.
> 
> That argument is like claiming that adding an amd64 profile to the tree
> is a potential screwup because x86 users might use it.

x86 users could at *least* render the profile out properly.  All 
gentoo users sans the few paludis experimenters cannot use N profile 
inheritance, and portage will misbehave with it.  Wrong profile is 
pretty damn obvious (compilation failure)- partially loaded profile is 
a bit different however, you only get part of the profile tree loaded 
(likely enough to continue on), but not all of it's settings.

Bit retarded here, but seriously, work it out in the overlay (like 
most herds do), then try to bring it to the tree.


> | Bluntly, you break compatibility with vdb/tree, paludis has no real 
> | future with gentoo beyond forking- requiring 100,000 users to 
> | reinstall because you don't want to do backwards compatibility is 
> | daft.
> 
> A reinstall isn't needed at all.

Currently is, going by your docs (and last look through code)- url?


> | The original discussion was about adding a paludis profile (not 
> | "portage sucks"), getting back to it, paludis is incompatible with 
> | portage at the actual ebuild level- considering that, why should the 
> | tree be modified to add a profile that's just going to introduce 
> | further breakage?
> 
> Paludis is no more incompatible with ebuilds than any new Portage
> release is.

Rhetoric.  I've pointed out specific changes you've gone and done that 
render it incompatible, and the response is "portage does it worse"?  
Portage doesn't willy nilly convert/drop vars, nor screw with the env 
handling.

Env handling *is* a bitch to get it properly- the ebd based 
portage-2.1 already demonstrated it, and all that was doing was 
*fixing* the statefullness of the env, not hacking all local data out.

That and the thread is getting fairly wide in discusion, rather then 
the profile specific "does alt pkg manager X cruft belong in the 
tree?"
~brian

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 12:55:11 -0700 Brian Harring <ferringb@gmail.com>
wrote:
| > That's not really true. Relying upon "anything that Portage
| > handles", including relying upon Portage bugs and internals, leads
| > to broken ebuilds when said things change.
| 
| ...which is why the ebuild env for portage is extremely carefully 
| maintained- mistakes may occur, but willy nilly changes don't.  
| Regardless, at least for gentoo it still however *is* the standard 
| for ebuilds, breaking the 'standard' out of portage is fine, changing 
| intrinsic parts of the standard isn't.

What standard?

| > You're acting like Paludis is dropping something huge here. Not
| > emulating a few weird PORTAGE_ variables that nothing uses is not
| > breaking eapi. If ebuilds genuinely rely upon something, we emulate
| > as necessary.
| 
| Then I'll state it again; you're changing the core environment 
| handling via intentionally dropping all local vars defined per phase 
| run.

Yes, we're intentionally not emulating a Portage misfeature and will
carry on not doing so until we come across a genuine case where this
causes breakage that isn't better fixed by other means. We haven't said
we definitely won't hack Paludis to make local variables not actually
local the way Portage does. Equally, we're not going to make that
change unless there's a damned good reason to do so.

| Add binpkgs, and try it- you'll get some fun behaviour there.

As we're not emulating Portage's binary package format, it's not an
issue at all.

| > *shrug* Your perception on this one's probably skewed if (as it
| > seems) you've been focusing on the trivial and easily replaceable
| > bash part, rather than the interesting things which are done in C++.
| 
| The bash part is all that matters, hence why I'm focusing on it- as 
| you stated above, the data (ebuilds) handling is what matters.  

A lot of the ebuild handling (especially environment) is done in C++.
You're missing all kinds of things by only looking at the bash code.

| > There is a difference between "changes that affect people not using
| > the newer package manager" and "changes that are only relevant to
| > people using the newer package manager". Anyone asking for features
| > that will lead to Portage breaking will be beaten with a spork.
| 
| N profile inheritance breaks portage.
| You were saying?

N profile inheritance does not break Portage unless someone mis-sets
their profile. Plenty of changes have been made that would trigger the
same class of breakage were the user to mis-set their profile. We are
not asking for N inheritance in profiles that will be used by Portage.

| Feel free to suggest them- since it's initial discussion, your 
| comments on it haven't really progressed beyond "y'all did it badly", 
| without naming a solution that works.

I gave you two that worked. One, the .ebuild.n thing, which avoids the
filename incompatibility issue and the source issue. Two, the "eapi as a
function" thing, which avoids the source issue.

| > Had you read the source or the documentation, you'd know fine well
| > that we support eclass unified overlays. I really think you should
| > refrain from making those kinds of claims until you actually have
| > the slightest clue what you're talking about.
| 
| Offhand, you're ignoring the point about lack of translation script 
| for vdb, and that paludis requires a new install.

Doesn't actually require it. It's just a good idea to do so, and we're
not going to support people who don't *at this stage*.

| Re: eclass, had to dig in the src for that one, doc's don't cover
| it.

Sure they do. It's included as part of the bootstrap howto doc.

| Your repositories support specifying an arbitrary eclass- they do
| not support the standard unification on the fly of eclass that most 
| portage users use- *technically* it can be done via copying eclasses 
| from each repo into an eclass directory (better yet symlinks), but 
| that's not unifying- that's working around the implementation.

Which is a good thing. Rather than emulating one of Portage's sillier
misfeatures, which only came about because of the whole "single
repository" concept being hard-coded, we did it properly.

| > Huh? Profiles that some Portage versions can't use have been added
| > plenty of times previously.
| 
| Yep, and we still get bugs about .50- that doesn't mean it's right 
| (just because someone else did something stupid doesn't mean you
| can). It's pretty simple, don't stick stuff into the tree that can
| silently fail, stick stuff in that is detected instead of silent
| failures.

It won't be a silent failure.

| > | Point is, the tree (you're own words) is not a playground, nor is
| > | it a demoscene- don't introduce the potential for screwup in the
| > | tree without a damn good reason.
| > 
| > That argument is like claiming that adding an amd64 profile to the
| > tree is a potential screwup because x86 users might use it.
| 
| x86 users could at *least* render the profile out properly.  All 
| gentoo users sans the few paludis experimenters cannot use N profile 
| inheritance, and portage will misbehave with it.  Wrong profile is 
| pretty damn obvious (compilation failure)- partially loaded profile
| is a bit different however, you only get part of the profile tree
| loaded (likely enough to continue on), but not all of it's settings.

No no, it can be made to explode as noisily as we like.

| Bit retarded here, but seriously, work it out in the overlay (like 
| most herds do), then try to bring it to the tree.

Oh, we already went through that stage.

| > | Bluntly, you break compatibility with vdb/tree, paludis has no
| > | real future with gentoo beyond forking- requiring 100,000 users
| > | to reinstall because you don't want to do backwards compatibility
| > | is daft.
| > 
| > A reinstall isn't needed at all.
| 
| Currently is, going by your docs (and last look through code)- url?

Isn't going to be documented, because I don't want people doing that
just now.

| > Paludis is no more incompatible with ebuilds than any new Portage
| > release is.
| 
| Rhetoric.  I've pointed out specific changes you've gone and done
| that render it incompatible, and the response is "portage does it
| worse"? Portage doesn't willy nilly convert/drop vars, nor screw with
| the env handling.

Not emulating Portage bugs isn't an incompatibility.

| That and the thread is getting fairly wide in discusion, rather then 
| the profile specific "does alt pkg manager X cruft belong in the 
| tree?"

Well yes, because rather than discussing the issues, you're trying to
turn this into your personal crusade against Paludis.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Tue, May 16, 2006 at 03:56:38PM -0700, Brian Harring wrote:
> If your parent parsing implementation handled N parents on a single 
> line (rather then parent per line as you do now), portage would 
> explode rather then silently use the left most.  Your implementation 
> isn't doing that however...

And that won't even work.  Woot.  About the only guranteed "portage 
will choke and not invalidly use N parent profiles if it doesn't 
support it are"-
1) specify the parents prefixed with #, fex
# ..
# ../blah
End result is that python will throw a TypeError (might be 
ValueError).  Not incredibly clean.
2) insane profile inheritance version trick.  Require the 
leftmost parent to point at a custom profile, say profiles/version1, 
which has a nice little bashrc along the lines of 
die "upgade your $PKG_MANAGER- your current version cannot parse this 
profile properly".
If the package manager knows of version1, it just filters that parent 
out as it goes- if it doesn't, any/all ebuild actions result in a 
forced bail as soon as control is transfered over to ebuild env.

Both solutions suck, and the alternatives of "just ignore it" or 
"require left parsed profile to be minimally sane" don't cut it all 
that well.

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 15:56:38 -0700 Brian Harring <ferringb@gmail.com>
wrote:
| This whole thing seems a bit dumb; it's not that far off from someone 
| coming along with a non-compliant c compiler, and arguing that
| they're still compliant, they just dropped the stupid stuff they
| didn't like.

And this is why your whole argument is nonsensical. C is a documented
and fixed standard (or rather, several of them). 

| > | Add binpkgs, and try it- you'll get some fun behaviour there.
| > 
| > As we're not emulating Portage's binary package format, it's not an
| > issue at all.
| 
| Doesn't matter *how* you bundle the ebuild data (cpio/tar/whatever), 
| the issue of reloading the env still will exist, the container for 
| the data doesn't matter.

What's your point?

| > A lot of the ebuild handling (especially environment) is done in
| > C++. You're missing all kinds of things by only looking at the bash
| > code.
| 
| And portage does a lot of crazy shit in python for env handling
| also. Sooner or later however, it hands control over to bash with a 
| pregenerated environment for the ebuild to execute in- what I keep 
| pointing out (and you keep dodging) is that the ebuild env *must* be 
| consistant, regardless of the actual pkg manager implementation.

And hey, we do provide a consistent environment.

| You deviate from the standard of the tree, you break your support 
| for the tree.  Pretty simple, users being the ones who see the mess.

Ok, so the *tree* is the standard now, not Portage? That's good,
because the tree is the standard we're using.

| > | Feel free to suggest them- since it's initial discussion, your 
| > | comments on it haven't really progressed beyond "y'all did it
| > | badly", without naming a solution that works.
| > 
| > I gave you two that worked. One, the .ebuild.n thing, which avoids
| > the filename incompatibility issue and the source issue. Two, the
| > "eapi as a function" thing, which avoids the source issue.
| 
| 1) sucks- folks aren't going to be happy when they have 
| mplayer-1.0.1.ebuild.25

Yes, but unfortunately it's the only way around Portage exploding
horribly when it encounters something it doesn't understand.

| 2) EAPI as a function is no different then EAPI as a var, just 
| massively slower since you have to shell out more.

Untrue. If the eapi function checks that the eapi is supported and
bails with an understandable error if not, the rest of the file doesn't
have to be source compatible.

| > Which is a good thing. Rather than emulating one of Portage's
| > sillier misfeatures, which only came about because of the whole
| > "single repository" concept being hard-coded, we did it properly.
| 
| So... let me see if I grok this- last response, state it supports 
| eclass unified overlays (blurb above).  Now you're stating that it 
| doesn't, because it's one of portage's misfeatures.  Please don't 
| waste the bandwidth doing that again.

Try defining your terms properly. It supports overlays with a unified
eclass directory. It doesn't support overlays with unified eclasses
from different directories.

| Stating it "won't be a silent failure" does not make it so- line 1023 
| of portage.py directly contradicts that.

There are other ways of making Portage fail non-silently, as you know
fine well.

| If your parent parsing implementation handled N parents on a single 
| line (rather then parent per line as you do now), portage would 
| explode rather then silently use the left most.  Your implementation 
| isn't doing that however...

Disallows spaces in paths. Which, admittedly, is probably a good thing.

| > | Bit retarded here, but seriously, work it out in the overlay
| > | (like most herds do), then try to bring it to the tree.
| > 
| > Oh, we already went through that stage.
| 
| So... where's the sample profile? :)

Elsewhere in the thread.

| > | That and the thread is getting fairly wide in discusion, rather
| > | then the profile specific "does alt pkg manager X cruft belong in
| > | the tree?"
| > 
| > Well yes, because rather than discussing the issues, you're trying
| > to turn this into your personal crusade against Paludis.
| 
| Sorry you see it that way, meanwhile kindly address the points I've 
| been raising

What points? When you start coming up with points relevant to a Paludis
profile and stop using this as a personal vendetta I might be
interested.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Paludis and Profiles

[Duncan]

Brian Harring <ferringb@gmail.com> posted
20060516225638.GB29839@nightcrawler, excerpted below, on  Tue, 16 May 2006
15:56:38 -0700:

> This whole thing seems a bit dumb; it's not that far off from someone 
> coming along with a non-compliant c compiler, and arguing that they're 
> still compliant, they just dropped the stupid stuff they didn't like.
> 
> They're still incompatible...

Interesting you bring that up.  There are C standards independent of any
individual implementation.  A compiler that doesn't comply with those
standards is noncompliant, by definition.  OTOH, a compiler that doesn't
comply with J Random implementation may or may not be standards compliant,
because J Random implementation doesn't define the standard.

The point argued here is that there isn't such an implementation
independent standard for a Gentoo package manager.  Arguing that the
standard is portage is hardly different than arguing that the standard for
certain network environments is... Well, let's just say there's a certain
anti-trust case going on about it at the moment.  How can one possibly
write to such a "standard"?

Now, I'm not saying the current profile proposal is something I support,
I'll deal with that in a different reply, but let's be clear, there are
standards, and there is portage, and portage does not a standard define. 
If one is going to argue that a standard must be supported, that standard
should exist as more than the code of a single implementation.  A standard
that doesn't exist as such cannot be a reasonable requirement for
support.

-- 
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] Paludis and Profiles

[Mark Loeser]

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

Brian Harring <ferringb@gmail.com> said:
> So... short version, introduction of the profile allows for curious 
> users to get bit in the ass by intentional dropping of compatibility 
> (profile level changes are one thing, changing the ebuild standard is 
> another).  In light of that, why should it be demoed in the tree where 
> the only use of it is to bootstrap a new installation?  Just overlay 
> it, y'all should be maintaining an overlay fixing ebuild incompatibilities 
> anyways.

Just my two cents,

I completely agree.  There are going to be lots of things that Paludis
supports that Portage doesn't, and maybe pkgcore doesn't either, so it
seems to make the most sense to keep it separate.  I don't think we
should start making changes to the tree for another package manager,
pkgcore or paludis.

No offense to either project.  If one of them one day replaces Portage,
it will have my complete support, but until then, we should focus on
keeping changes in the tree to a minimum for other package managers.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

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

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 16 May 2006 18:55, Mark Loeser wrote:
> No offense to either project.  If one of them one day replaces Portage,
> it will have my complete support, but until then, we should focus on
> keeping changes in the tree to a minimum for other package managers.
++ for Halcy0n, and adding from an ebuild maintainer some more, many parts of 
the current tree are at a minimum understaffed, if we're going to have to 
start dealing with bugs coming from users experimenting with something else 
but portage, we'd be _really_ taken over.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 19:06:24 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| ++ for Halcy0n, and adding from an ebuild maintainer some more, many
| parts of the current tree are at a minimum understaffed, if we're
| going to have to start dealing with bugs coming from users
| experimenting with something else but portage, we'd be _really_ taken
| over.

That's rather funny, when one considers the whole BSD profile structure
and the zillions of ebuild changes that've been made for BSD.

Be realistic here. The changes for Paludis are tiny compared to the
changes that have been required for various Portage upgrades.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 16 May 2006 19:20, Ciaran McCreesh wrote:
> That's rather funny, when one considers the whole BSD profile structure
> and the zillions of ebuild changes that've been made for BSD.
You're just FUDing this and you know, the changes are rather minimal, and all 
directly handled by me (the BSD team), not handled down to maintainers at 
all.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 19:35:32 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Tuesday 16 May 2006 19:20, Ciaran McCreesh wrote:
| > That's rather funny, when one considers the whole BSD profile
| > structure and the zillions of ebuild changes that've been made for
| > BSD.
|
| You're just FUDing this and you know, the changes are rather minimal,
| and all directly handled by me (the BSD team), not handled down to
| maintainers at all.

And yet, the changes we're after are far tinier. Somehow I don't think
we're the ones spreading the FUD here. We're not asking for zillions of
ebuild changes and keywording.

(Not that I'm opposed to BSD, as you know. I just find it rather
strange that you're using a "big change" argument here...)

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 16 May 2006 21:51, Ciaran McCreesh wrote:
> Somehow I don't think 
> we're the ones spreading the FUD here.
Should I call you an hypocrite or you'll apologise after calling me a FUD 
spreader?

> (Not that I'm opposed to BSD, as you know. I just find it rather
> strange that you're using a "big change" argument here...)
Let's see:

On Tuesday 16 May 2006 19:06, Diego 'Flameeyes' Pettenò wrote:
> ++ for Halcy0n, and adding from an ebuild maintainer some more, many parts
> of the current tree are at a minimum understaffed, if we're going to have
> to start dealing with bugs coming from users experimenting with something
> else but portage, we'd be _really_ taken over.

I didn't say "big", I didn't say "change", I didn't even refer to the profile 
itself. I agreed with Halcy0n's post and I said that dealing with bugs that 
might be coming out of portage's misbehaviours being depended on might make 
us get taken over by bugs.

So I didn't appeal to any "big change" argument, and you're still missing your 
point.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 22:09:10 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Tuesday 16 May 2006 19:06, Diego 'Flameeyes' Pettenò wrote:
| > ++ for Halcy0n, and adding from an ebuild maintainer some more,
| > many parts of the current tree are at a minimum understaffed, if
| > we're going to have to start dealing with bugs coming from users
| > experimenting with something else but portage, we'd be _really_
| > taken over.
| 
| I didn't say "big", I didn't say "change", I didn't even refer to the
| profile itself. I agreed with Halcy0n's post and I said that dealing
| with bugs that might be coming out of portage's misbehaviours being
| depended on might make us get taken over by bugs.

Perhaps you should've read Halcy0n's post:

> I don't think we should start making changes to the tree for another
> package manager, pkgcore or paludis.

Looks like you were agreeing with a "change" argument to me.

| So I didn't appeal to any "big change" argument, and you're still
| missing your point.

Ooh, so it's a "small change" argument? That's even more hypocritical.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 16 May 2006 22:52, Ciaran McCreesh wrote:
> Perhaps you should've read Halcy0n's post:
Perhaps you should think before writing, before acting, before doing 
anything... perhaps you should _think_, period.

[For userrel happyness: I'm being _volunteering_ harassing him at this point, 
and you know what? I don't care, as he's just trying to make a fool of me, at 
the very least. If he really thinks what he's writing about me, like not 
being able to read what Halcy0n's said, I really feel pity for him.]

> Looks like you were agreeing with a "change" argument to me.
And providing my own reasons for the agreement.

> Ooh, so it's a "small change" argument? That's even more hypocritical.
Oooh so it's a "you did a mistake and now you try to make me pass for the 
fool" argument, isn't it?

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 23:03:35 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Tuesday 16 May 2006 22:52, Ciaran McCreesh wrote:
| > Perhaps you should've read Halcy0n's post:
| Perhaps you should think before writing, before acting, before doing 
| anything... perhaps you should _think_, period.

Oh, I do. Which is why I'm not the one posting nonsensical and
incoherent rants to a mailing list.

| [For userrel happyness: I'm being _volunteering_ harassing him at
| this point, and you know what? I don't care, as he's just trying to
| make a fool of me, at the very least. If he really thinks what he's
| writing about me, like not being able to read what Halcy0n's said, I
| really feel pity for him.]

I didn't say you weren't able. I said you didn't.

| > Ooh, so it's a "small change" argument? That's even more
| > hypocritical.
| Oooh so it's a "you did a mistake and now you try to make me pass for
| the fool" argument, isn't it?

Ok, now you're really not making any sense. I can only assume that
you're replacing "dazzle them with rhetoric" with "baffle them with
incoherence".

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

Diego 'Flameeyes' Pettenò wrote:
> You're just FUDing this and you know, the changes are rather minimal, and all 
> directly handled by me (the BSD team), not handled down to maintainers at 
> all.

They're rather minimal, and still an order of magnitude larger than what 
I'm proposing here.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 13 June 2006 20:27, Stephen Bennett wrote:
> They're rather minimal, and still an order of magnitude larger than what
> I'm proposing here.
Right, the point is not the change in itself but the way people are going to 
experimenting with it.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Luis Francisco Araujo]

Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 13 June 2006 20:27, Stephen Bennett wrote:
>   
>> They're rather minimal, and still an order of magnitude larger than what
>> I'm proposing here.
>>     
> Right, the point is not the change in itself but the way people are going to 
> experimenting with it.
>
>   
Sorry if i am confusing things here, but isn't this just _yet_ another
profile that
the user can choose to use?, And if it is so, i think it'd be nice for
both developers
and our user base to have such an alternative.
 
It will be at the end up to the final user to give it a try or not,
assuming their respective
risks (if any).
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 16 May 2006 21:35, Luis Francisco Araujo wrote:
> Sorry if i am confusing things here, but isn't this just _yet_ another
> profile that
> the user can choose to use?
A profile in the tree has to be supported by someone.
It's also more likely that people would try it out without knowing what they 
are going to open.

An overlay makes users more conscious that they are going to require manual 
work and they have to know where to look for support. If it's in portage, 
it's more likely that users won't look at it deeply and just think that "it's 
portage, so goes to gentoo bugzilla".

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Jan Kundrát]

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

Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 16 May 2006 21:35, Luis Francisco Araujo wrote:
> 
>>Sorry if i am confusing things here, but isn't this just _yet_ another
>>profile that
>>the user can choose to use?
> 
> A profile in the tree has to be supported by someone.
> It's also more likely that people would try it out without knowing what they 
> are going to open.
> 
> An overlay makes users more conscious that they are going to require manual 
> work and they have to know where to look for support. If it's in portage, 
> it's more likely that users won't look at it deeply and just think that "it's 
> portage, so goes to gentoo bugzilla".

See /usr/portage/profiles/default-linux/x86/dev/README :)

Blesmrt,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


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

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 16 May 2006 22:13, Jan Kundrát wrote:
> See /usr/portage/profiles/default-linux/x86/dev/README :)
You think the phrase "RTFM" would have ever been forged if people actually 
read that stuff?

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Luis Francisco Araujo]

Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 16 May 2006 22:13, Jan Kundrát wrote:
>   
>> See /usr/portage/profiles/default-linux/x86/dev/README :)
>>     
> You think the phrase "RTFM" would have ever been forged if people actually 
> read that stuff?
>
>   

This is pretty much true for trying out any new stuff.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Tue, 2006-05-16 at 22:13 +0200, Jan Kundrát wrote:
> Diego 'Flameeyes' Pettenò wrote:
> > On Tuesday 16 May 2006 21:35, Luis Francisco Araujo wrote:
> > 
> >>Sorry if i am confusing things here, but isn't this just _yet_ another
> >>profile that
> >>the user can choose to use?
> > 
> > A profile in the tree has to be supported by someone.
> > It's also more likely that people would try it out without knowing what they 
> > are going to open.
> > 
> > An overlay makes users more conscious that they are going to require manual 
> > work and they have to know where to look for support. If it's in portage, 
> > it's more likely that users won't look at it deeply and just think that "it's 
> > portage, so goes to gentoo bugzilla".
> 
> See /usr/portage/profiles/default-linux/x86/dev/README :)

Yeah, except that's a lie.  I actually do support it.  That is mostly
there to let people know that I do play around in there and have been
known to break things in the past.  It is where I do all of the profile
work before a release, so I might play with ideas that do things that a
user might not want.

Basically, I don't follow the same "be very careful before adding stuff"
mantra in there as I would on default-linux/x86.  That being said, I
don't put anything there that I don't have *somebody* out there testing,
so it's known to work on at least a few systems.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

Diego 'Flameeyes' Pettenò wrote:
> A profile in the tree has to be supported by someone.

It will be supported by me, and the other devs involved with Paludis.

> It's also more likely that people would try it out without knowing what they 
> are going to open.

So we will add a big fat README, as with all the other experimental / 
possibly broken profiles, warning users.

> If it's in portage,
> it's more likely that users won't look at it deeply and just think that "it's 
> portage, so goes to gentoo bugzilla".

There's enough precedent in the tree for specifically telling users to 
file bugs elsewhere that I don't see this as a great problem.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 13 June 2006 22:30, Stephen Bennett wrote:
> It will be supported by me, and the other devs involved with Paludis.
Okay, then I suppose you might want first to create a project to handle the 
profile and the whole bugs load that might come out of that. And make sure 
that bug-wranglers and all the teams are well informed how to identify people 
using paludis and where to redirect all those bugs to (so you need an alias 
on Bugzilla I'd say).

This is the minimum first step.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Tue, 16 May 2006 22:59:59 +0200
"Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:

> Okay, then I suppose you might want first to create a project to
> handle the profile and the whole bugs load that might come out of
> that.

Does every profile need a project to maintain it now? That's never been
the case as far as I was aware. If people want a project though, I can
create one.

> And make sure that bug-wranglers and all the teams are well
> informed how to identify people using paludis and where to redirect
> all those bugs to (so you need an alias on Bugzilla I'd say).

Jakub: Any bugs where the user is using a paludis profile go to
spb@gentoo.org for now. Since profile is among the information we
routinely ask for on bug reports, identifying them shouldn't be a
problem.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Tuesday 16 May 2006 23:47, Stephen Bennett wrote:
> On Tue, 16 May 2006 22:59:59 +0200
>
> "Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:
> > Okay, then I suppose you might want first to create a project to
> > handle the profile and the whole bugs load that might come out of
> > that.
>
> Does every profile need a project to maintain it now? That's never been
> the case as far as I was aware. If people want a project though, I can
> create one.

Everything in the tree, including profiles, must be maintained by a 
project. One project may maintain 50 profiles, but there must be an 
identifyable GROUP of people responsible for anything in the tree, 
including profiles. (This has been true for at least 3 years, and was one 
of the main factors behind the herds thing). The group point is because 
that makes unsupported stuff less likely in the case of someone leaving.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Tue, 2006-05-16 at 22:47 +0100, Stephen Bennett wrote:
> On Tue, 16 May 2006 22:59:59 +0200
> "Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:
> 
> > Okay, then I suppose you might want first to create a project to
> > handle the profile and the whole bugs load that might come out of
> > that.
> 
> Does every profile need a project to maintain it now? That's never been
> the case as far as I was aware. If people want a project though, I can
> create one.

Well, hardened/* and selinux/* are controlled by the Hardened Project,
the Embedded Project controls uclibc/* and embedded/*, and Release
Engineering (basically) controls default-linux with the assistance of
the architecture teams, which are a part of the Base Project.  The
base/* profile is generally a collaboration of the above teams.  The
default-bsd/* and default-darwin/* profiles are controlled by the
Gentoo/*BSD and Gentoo/Mac OS X Projects, respectively.

So while there's no rule set in stone that a project exists, it is a
generally followed practice.

I would say it wouldn't hurt to start a project for ensuring Paludis
support in the Portage tree.  It would give a bit more credibility to
your cause.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 09:42:50 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> I would say it wouldn't hurt to start a project for ensuring Paludis
> support in the Portage tree.  It would give a bit more credibility to
> your cause.

The problem that I see with this is that it would tend to reinforce the
view that Paludis is becoming an officially supported package manager,
which at the moment at least it isn't. If people are amenable to the
idea though, I'm quite willing to set it up.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 16:08, Stephen Bennett wrote:
> On Wed, 17 May 2006 09:42:50 -0400
>
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > I would say it wouldn't hurt to start a project for ensuring Paludis
> > support in the Portage tree.  It would give a bit more credibility to
> > your cause.
>
> The problem that I see with this is that it would tend to reinforce the
> view that Paludis is becoming an officially supported package manager,
> which at the moment at least it isn't. If people are amenable to the
> idea though, I'm quite willing to set it up.

In my opinion if paludis is not aiming to become an officially supported 
package manager there is no point in changing the tree to that in the 
first place.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 17:29:11 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> > The problem that I see with this is that it would tend to reinforce
> > the view that Paludis is becoming an officially supported package
> > manager, which at the moment at least it isn't. If people are
> > amenable to the idea though, I'm quite willing to set it up.
> 
> In my opinion if paludis is not aiming to become an officially
> supported package manager there is no point in changing the tree to
> that in the first place.

Note "at the moment". We want paludis to be a viable alternative to
Portage for most users, and part of that aim requires having an
available profile that doesn't bring Portage into the system set. An
"officially supported" package manager is a pretty vague term
anyway ... there's a group within Gentoo that will support it, and
groups that won't, as with any other part of the tree.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 18:25, Stephen Bennett wrote:
> On Wed, 17 May 2006 17:29:11 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > > The problem that I see with this is that it would tend to reinforce
> > > the view that Paludis is becoming an officially supported package
> > > manager, which at the moment at least it isn't. If people are
> > > amenable to the idea though, I'm quite willing to set it up.
> >
> > In my opinion if paludis is not aiming to become an officially
> > supported package manager there is no point in changing the tree to
> > that in the first place.
>
> Note "at the moment". We want paludis to be a viable alternative to
> Portage for most users, and part of that aim requires having an
> available profile that doesn't bring Portage into the system set. An
> "officially supported" package manager is a pretty vague term
> anyway ... there's a group within Gentoo that will support it, and
> groups that won't, as with any other part of the tree.

Officially supported means that package maintainers must take it into account. 
Repoman (or another QA tool) checks for compatibility on it, etc.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ilya A. Volynets-Evenbakh]

Stephen Bennett wrote:
> On Wed, 17 May 2006 09:42:50 -0400
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
>
>   
>> I would say it wouldn't hurt to start a project for ensuring Paludis
>> support in the Portage tree.  It would give a bit more credibility to
>> your cause.
>>     
>
> The problem that I see with this is that it would tend to reinforce the
> view that Paludis is becoming an officially supported package manager,
> which at the moment at least it isn't. If people are amenable to the
> idea though, I'm quite willing to set it up.
>   

And I am willing to be part of it.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 12:55:11 -0400 Mark Loeser <halcy0n@gentoo.org>
wrote:
| I completely agree.  There are going to be lots of things that Paludis
| supports that Portage doesn't, and maybe pkgcore doesn't either, so it
| seems to make the most sense to keep it separate.  I don't think we
| should start making changes to the tree for another package manager,
| pkgcore or paludis.

You make "making changes to the tree" sound so extremely dramatic.
Stephen is asking for a new subprofile, not for a few thousand ebuilds
to be changed (which is something that's been done in the past for
new Portage versions).

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

Brian Harring wrote:
> So... short version, introduction of the profile allows for curious 
> users to get bit in the ass by intentional dropping of compatibility 
> (profile level changes are one thing, changing the ebuild standard is 
> another).  In light of that, why should it be demoed in the tree where 
> the only use of it is to bootstrap a new installation?  Just overlay 
> it, y'all should be maintaining an overlay fixing ebuild incompatibilities 
> anyways.

This I see as a non-argument. We imitate enough of Portage's 
idiosyncracies to support every ebuild with which we've tested it, so 
the ebuild format is for all intents and purposes the same. Sure, a few 
internal variables have different names, but those are the ones that 
ebuilds generally shouldn't be using, and if there is a legitimate case 
where they are used, we emulate it. And it would have uses beyond 
bootstrapping a new installation-- for example, say, running a system 
exactly as any other profile is used.

> The gain of the profile is that you can do a few new tricks for folks 
> doing boostrapping experiments- why not just introduce an ebuild that 
> sets up the new profile in a temp overlay?

No, the gain is that one could sanely run a Paludis-based system without 
needing an external overlay, and without having to update said overlay 
whenever the base profiles in the tree change.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Tue, Jun 13, 2006 at 06:28:41PM +0100, Stephen Bennett wrote:
> Brian Harring wrote:
> >The gain of the profile is that you can do a few new tricks for folks 
> >doing boostrapping experiments- why not just introduce an ebuild that 
> >sets up the new profile in a temp overlay?
> 
> No, the gain is that one could sanely run a Paludis-based system without 
> needing an external overlay, and without having to update said overlay 
> whenever the base profiles in the tree change.

Bluntly, why should the tree be modified for a minority?  Being 
generous, lets pretend y'all have 300 users- why should incompatible 
changes be added to the tree (say 300k users) that can bite 299,700 
users in the ass for the benefit of 300 users?  N parent inherited 
profiles *is* a change that can bite users in the ass, and it's not an 
obvious incompatibility unless you know it exists.

Ebuild level incompatibility is there also, and the only way that's 
going to be resolved is by inspection of each ebuild.

Note I said inspection- just the same as loosing the USE flag state 
for when re-executing the env for an unmerge, loosing local non 
exported vars has the same potential for change.

Not opposed to y'all ironing it out in an overlay and proposing the 
switch (with a sane transition plan)- am opposed to the "lets just do 
it and ignore the consequences to the userbase" mentality that such 
requests imply.

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

Brian Harring wrote:
> Bluntly, why should the tree be modified for a minority?  Being 
> generous, lets pretend y'all have 300 users- why should incompatible 
> changes be added to the tree (say 300k users) that can bite 299,700 
> users in the ass for the benefit of 300 users?  N parent inherited 
> profiles *is* a change that can bite users in the ass, and it's not an 
> obvious incompatibility unless you know it exists.

By this logic, let's remove all the default-bsd, default-darwin, 
embedded, arm, and sh profiles. They're only used by a tiny minority, 
and switching an x86/linux system's profile to one of them will hork 
things majorly. I'm really not seeing your argument here.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Christian Hartmann]

> If noone has any strong reasonable objections, I'd like to add a
> Paludis profile to the tree.

Oh lovely. - If noone has any strong reasonable objections, I'd like to add a 
$ians-playground profile to the tree. Furthermore I will start to keywording 
ebuilds with the new ~fridge keyword I just invented.

> The next question is where to put it. The options as I see them are
> under default-linux/x86/ or in a top-level paludis/ a la hardened,
> selinux, embedded, and the like.

How is paludis related to gentoo? Hardened and the other things you mentioned 
are gentoo projects. - Paludis is not.

> That's my proposal. The benefits I like to think are obvious. The
> drawbacks are, as far as I can see, in tree size, which should be
> minimal. Those concerned about local tree size can exclude it, and for
> size on the mirrors it's trivial compared to the rest of the tree.

It's not about the size or the number of files. We have got enough - let's 
call it $stuff - in the tree. I'd really like to see valid and reasonable 
things added to the tree. - Adding things just because someone thinks it 
would be funny to add it to the tree can't be the way gentoo wants to go.

> Comments?

Looking at the comment left for end-users on the paludis homepage [1] I'm 
still wondering why paludis is not package.mask'ed as it's known to break 
users systems.

[1] http://paludis.berlios.de/

-- 
Christian Hartmann
http://www.gentoo.org/~ian/

PGP Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865
Key fingerprint = 4544 EC0C BAE4 216F 5981  7F95 2154 E5EE 692A 4865

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 19:10:18 +0200 Christian Hartmann <ian@gentoo.org>
wrote:
| Oh lovely. - If noone has any strong reasonable objections, I'd like
| to add a $ians-playground profile to the tree. Furthermore I will
| start to keywording ebuilds with the new ~fridge keyword I just
| invented.

Why yes, because we're asking for people to go around changing all
their ebuilds. Oh, wait! We're not! That argument is right up there
with saying that the Pope should be removed from office because he
personally murdered five million French soldiers in World War II.

Please try to come up with something sliiightly more plausible than that
when you're trying to attack something based upon your personal
prejudices. Or is that really the best criticism you can find?

| > The next question is where to put it. The options as I see them are
| > under default-linux/x86/ or in a top-level paludis/ a la hardened,
| > selinux, embedded, and the like.
| 
| How is paludis related to gentoo? Hardened and the other things you
| mentioned are gentoo projects. - Paludis is not.

Phony argument. Paludis is a package that's in the tree, and profile
changes are regularly made for packages that are in the tree.

| It's not about the size or the number of files. We have got enough -
| let's call it $stuff - in the tree. I'd really like to see valid and
| reasonable things added to the tree. - Adding things just because
| someone thinks it would be funny to add it to the tree can't be the
| way gentoo wants to go.

If you care about the size of the tree, why not start by nuking a few
dozen broken and unmaintained x11-* packages? They're not hard to find,
and unlike Paludis they aren't useful to anyone.

| Looking at the comment left for end-users on the paludis homepage [1]
| I'm still wondering why paludis is not package.mask'ed as it's known
| to break users systems.

Unfortunately, that warning has to be there to protect Paludis from
rampaging hordes of forums users and the like who otherwise would do
something very very dumb. Paludis is less likely to break your system
than reiserfs.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Christian Hartmann]

> Please try to come up with something sliiightly more plausible than that
> when you're trying to attack something based upon your personal
> prejudices. Or is that really the best criticism you can find?

Uh yeah. It's all just based on my personal prejudices. - Why did I give 
paludis a try (on several VMs) then first? Remember when paludis was 
segfaulting?

> Phony argument. Paludis is a package that's in the tree, and profile
> changes are regularly made for packages that are in the tree.

That's how you want to understand it. It's easy to pervert the facts if one 
just constantly writes the same FUD over and over again. But this doesn't 
change anything. People will become tired to discuss the profile changes. 
Then the profile will be added. - You win. - Hooray.

It has always been that way. - Changes won't be made because they are 
sensible. They will be made because people are sick off wasting their time on 
discussions like that. - So am I.

-- 
Christian Hartmann
http://www.gentoo.org/~ian/

PGP Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865
Key fingerprint = 4544 EC0C BAE4 216F 5981  7F95 2154 E5EE 692A 4865

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 07:03:27 +0200 Christian Hartmann <ian@gentoo.org>
wrote:
| > Please try to come up with something sliiightly more plausible than
| > that when you're trying to attack something based upon your personal
| > prejudices. Or is that really the best criticism you can find?
| 
| Uh yeah. It's all just based on my personal prejudices. - Why did I
| give paludis a try (on several VMs) then first? Remember when paludis
| was segfaulting?

Sure. You ran -svn (our release check procedures would have caught
that before it hit a release anyway), found a bug, and it got fixed and
a testcase was added to ensure that the same kind of issue didn't
reoccur. Did you want a cookie or something?

| That's how you want to understand it. It's easy to pervert the facts
| if one just constantly writes the same FUD over and over again. But
| this doesn't change anything. People will become tired to discuss the
| profile changes. Then the profile will be added. - You win. - Hooray.
| 
| It has always been that way. - Changes won't be made because they are 
| sensible. They will be made because people are sick off wasting their
| time on discussions like that. - So am I.

If you'd like far less time wasted on discussions, perhaps you and your
co-offenders should try not posting huge numbers of emails that are
free of technical objections.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Mike Frysinger]

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

On Tuesday 16 May 2006 13:10, Christian Hartmann wrote:
> > If noone has any strong reasonable objections, I'd like to add a
> > Paludis profile to the tree.
>
> Oh lovely. - If noone has any strong reasonable objections, I'd like to add
> a $ians-playground profile to the tree. Furthermore I will start to
> keywording ebuilds with the new ~fridge keyword I just invented.

if you dont have anything constructive to contribute then dont bother writing 
an e-mail
-mike

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

Re: [gentoo-dev] Paludis and Profiles

[Grant Goodyear]

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

Christian Hartmann wrote: [Tue May 16 2006, 12:10:18PM CDT]
> Oh lovely. - If noone has any strong reasonable objections, I'd like
> to add a $ians-playground profile to the tree. Furthermore I will
> start to keywording ebuilds with the new ~fridge keyword I just
> invented.

Hyperbole?

> How is paludis related to gentoo? Hardened and the other things you
> mentioned are gentoo projects. - Paludis is not.

That's not really a fair statement.  Porthole and various other tools
began (and in some cases remain) as non-Gentoo-owned projects, but
numerous portage changes have been made over the years to support those
tools better.

Paludis and pkgcore are related to gentoo because they are both designed
to work with Gentoo's portage tree.

> It's not about the size or the number of files. We have got enough - let's 
> call it $stuff - in the tree. I'd really like to see valid and reasonable 
> things added to the tree. - Adding things just because someone thinks it 
> would be funny to add it to the tree can't be the way gentoo wants to go.

It appears, at least from what I've read, that the additions to the tree
would be both minimal and narrowly focused.  Why would that not be valid
or reasonable?  Also, I don't believe that anybody is attempting to be
"funny", but instead to provide a potentially useful set of tools that
need a lot of hammering on.

> > Comments?

Wouldn't a paludis profile lead to an explosion of children profiles
that depend on it, or is the profile "mixed-in" with a standard profile?
In either case, might it be easier to have a /usr/portage/paludis
directory for paludis-specific content?  (The opposite, but equally
ignorant, question that I had was if it wouldn't be simpler to add the
paludis-specific stuff to the existing files, and have portage ignore
it.)

-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] Paludis and Profiles

[Stephen Bennett]

Christian Hartmann wrote:
> Oh lovely. - If noone has any strong reasonable objections, I'd like to add a 
> $ians-playground profile to the tree. Furthermore I will start to keywording 
> ebuilds with the new ~fridge keyword I just invented.

I'll take that to mean "no objection based in a technical argument" 
then. Thanks.

> Looking at the comment left for end-users on the paludis homepage [1] I'm 
> still wondering why paludis is not package.mask'ed as it's known to break 
> users systems.

If you're going to complain about it because the website is out of date, 
  I can p.mask half of base-system if you like.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Christian Hartmann]

Am Dienstag 13 Juni 2006 19:30 schrieb Stephen Bennett:
> Christian Hartmann wrote:
> > Oh lovely. - If noone has any strong reasonable objections, I'd like to
> > add a $ians-playground profile to the tree. Furthermore I will start to
> > keywording ebuilds with the new ~fridge keyword I just invented.
>
> I'll take that to mean "no objection based in a technical argument"
> then. Thanks.

You're welcome. - Obviously you didn't get the point. So please let me clarify 
my statement:

If paludis ever will be marked stable will developers have to test their 
packages to work with the latest stable paludis and the lastest stable 
portage? Users will expect ebuilds to work with paludis. You are saying that 
paludis does not require any changes made to any ebuilds in the 
gentoo-portage-tree. What if a stable paludis fails on a stable ebuild?

If I would add $ians-toolset to sys-apps and $ians-playgroud to profiles users 
will expect this stuff to be supported by gentoo.

In the end we (gentoo) will have to support the "other package manager" aka 
paludis because "if it's in the tree users will expect it to work and being 
supported". That's not what I'm going to do.

-- 
Christian Hartmann
http://www.gentoo.org/~ian/

PGP Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865
Key fingerprint = 4544 EC0C BAE4 216F 5981  7F95 2154 E5EE 692A 4865

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

Christian Hartmann wrote:
> It's not about the size or the number of files. We have got enough - let's 
> call it $stuff - in the tree. I'd really like to see valid and reasonable 
> things added to the tree. - Adding things just because someone thinks it 
> would be funny to add it to the tree can't be the way gentoo wants to go.

If I were adding it because I thought it would be funny, I would have 
done so by now. The very fact that I mailed -dev first should be 
indication enough that I think it's a reasonable addition and therefore 
want to do things properly.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Fernando J. Pereda]

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

On Tue, May 16, 2006 at 04:15:49PM +0100, Stephen Bennett wrote:
> Comments?

I'd like to see a paludis profile under default-linux/alpha. I belive it
is much better to have a top-level hierarchy for paludis profiles
anyway but people seem to blindly disagree with that.

Oh, and BTW, keep up the good work with paludis.

-ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] Paludis and Profiles

[Gustavo Zacarias]

Stephen Bennett wrote:

> That's my proposal. The benefits I like to think are obvious. The
> drawbacks are, as far as I can see, in tree size, which should be
> minimal. Those concerned about local tree size can exclude it, and for
> size on the mirrors it's trivial compared to the rest of the tree.
> 
> Comments?

As long as it's outside the "stable" (200x.y) portage profiles i'm fine 
with it for SPARC. I think Ferris was testing paludis so i'm sure he can 
handle it.
With respect to the "hey support omg!" comments i say stick a big fat 
README about being an experimental profile or something like that and 
that's it. Usually bug reports require "emerge --info" so it'll be easy 
to flag invalid ones anyway.

-- 
Gustavo Zacarias
Gentoo/SPARC monkey
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Danny van Dyk]

Am Dienstag, 16. Mai 2006 20:35 schrieb Gustavo Zacarias:
> Stephen Bennett wrote:
> > That's my proposal. The benefits I like to think are obvious. The
> > drawbacks are, as far as I can see, in tree size, which should be
> > minimal. Those concerned about local tree size can exclude it, and
> > for size on the mirrors it's trivial compared to the rest of the
> > tree.
> >
> > Comments?
>
> As long as it's outside the "stable" (200x.y) portage profiles i'm
> fine with it for SPARC. I think Ferris was testing paludis so i'm
> sure he can handle it.
> With respect to the "hey support omg!" comments i say stick a big fat
> README about being an experimental profile or something like that and
> that's it. Usually bug reports require "emerge --info" so it'll be
> easy to flag invalid ones anyway.

[Disclaimer: I'm involved in paludis development and may be biased]
I talked with the other AMD64 leads about adding a paludis subprofile to 
default-linux/amd64. Blubb said he'd rather have a global profile, 
Kingtaco state to be neutral in regard to adding another amd64 
subprofile. I'd rather have a global profile, too.

Summary: amd64 team can live with a paludis profile, we prefer to have a 
global profile, though.


PS:
As a sidenote to people who test or play with paludis and find packages 
that don't compile/install: Please don't file bugs with gentoo. Come to 
#paludis and discuss with us. If we tell you to do so, file bugs with 
paludis@berlios.de. We are really interested to know which packages 
don't work.

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Tue, 2006-05-16 at 21:05 +0200, Danny van Dyk wrote:
> Am Dienstag, 16. Mai 2006 20:35 schrieb Gustavo Zacarias:
> > Stephen Bennett wrote:
> > > That's my proposal. The benefits I like to think are obvious. The
> > > drawbacks are, as far as I can see, in tree size, which should be
> > > minimal. Those concerned about local tree size can exclude it, and
> > > for size on the mirrors it's trivial compared to the rest of the
> > > tree.
> > >
> > > Comments?
> >
> > As long as it's outside the "stable" (200x.y) portage profiles i'm
> > fine with it for SPARC. I think Ferris was testing paludis so i'm
> > sure he can handle it.
> > With respect to the "hey support omg!" comments i say stick a big fat
> > README about being an experimental profile or something like that and
> > that's it. Usually bug reports require "emerge --info" so it'll be
> > easy to flag invalid ones anyway.
> 
> [Disclaimer: I'm involved in paludis development and may be biased]
> I talked with the other AMD64 leads about adding a paludis subprofile to 
> default-linux/amd64. Blubb said he'd rather have a global profile, 
> Kingtaco state to be neutral in regard to adding another amd64 
> subprofile. I'd rather have a global profile, too.
> 
> Summary: amd64 team can live with a paludis profile, we prefer to have a 
> global profile, though.
> 
> 
> PS:
> As a sidenote to people who test or play with paludis and find packages 
> that don't compile/install: Please don't file bugs with gentoo. Come to 
> #paludis and discuss with us. If we tell you to do so, file bugs with 
> paludis@berlios.de. We are really interested to know which packages 
> don't work.

(Wearing my Release Engineering hat): I implore anyone planning on
adding something like this to keep it *outside* of default-linux.  A
paludis/* set of profiles, much like hardened or uclibc, would be the
best approach for this, if it ends up being accepted.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Tue, 16 May 2006 23:14:53 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> This should not be a side note IMHO. If that profile is in the tree,
> who in Gentoo will support it?

I will.

> Does the Gentoo Project not support the
> entire tree all of a sudden? 

There are plenty of ebuilds in the tree marked as unsupported by
gentoo. Probably some profiles too, though I can't name them for
certain off the top of my head.

> 1) Is bugsy ready for this, with appropriate categories in place?

Paludis-related bugs can be marked as invalid and the user directed to
Paludis' bug tracker on berlios.de. Alternatively, if our friendly
Bugzilla admins want to create categories I won't complain. I don't see
a need for it though.

> 2) Is there an alias addy for Paludis related issues, so that Paludis
> users can communicate with members of some Paludis profile team for
> support?

For issues related to Gentoo packaging of paludis, bugs can be filed
to the ebuild maintainer listed in metadata.xml. For other
paludis-related issues, there are mailing lists mentioned on the web
site.

> 3) Is documentation support in place to refer Paludis profile users to
> when they fail to understand "reason" and demand Gentoo support for
> issues with the Paludis profile?

http://paludis.berlios.de/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Carsten Lohrke]

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

On Wednesday 17 May 2006 00:22, Stephen Bennett wrote:
> > Does the Gentoo Project not support the
> > entire tree all of a sudden?
>
> There are plenty of ebuilds in the tree marked as unsupported by
> gentoo. Probably some profiles too, though I can't name them for
> certain off the top of my head.

That's not an argument, the share of both unsupported and unmaintaned packages 
is problematic enough. Unfortunately trying to find a way to change this 
every time resulted in some devs starting a flame war.

> 1) Is bugsy ready for this, with appropriate categories in place?
>
> Paludis-related bugs can be marked as invalid and the user directed to
> Paludis' bug tracker on berlios.de. Alternatively, if our friendly
> Bugzilla admins want to create categories I won't complain. I don't see
> a need for it though.

This costs someones time as well.


I haven't had a look at Paludis (the name sucks as much as the name eselect 
had, before it was named eselect, btw.) yet, so I don't have an opinion on 
it, but if we (or some of us) start supporting arbitrary package managers, 
where do we end? Doesn't it cost time, that could be spent better!? If we do 
it, wouldn't it be better to modularize a bit first? E.g. defining interfaces 
between 

- tarball management (fetching via users tool of choice be it from the web or 
according to a file list from a named media (e.g. DVD or a tape), mirror 
handling etc.)
- profile management (keeping the on disk representation apart from the way 
the dependency resolver gets the information)
- package management (dependency resolver, ect.)
- package installer (install files or create binary packages, may the target 
be .tbz2, .deb or .rpm)

and implement them as independent tools, so we can easly exchange one for the 
other, if there is a superior one, instead having to throw everything away?!


I don't think it would be beneficial in the long run, if the outcome would be 
that Gentoo divides into groups using different package managers.


Carsten

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 01:58:02 +0200 Carsten Lohrke <carlo@gentoo.org>
wrote:
| I haven't had a look at Paludis (the name sucks as much as the name
| eselect had, before it was named eselect, btw.) yet, so I don't have
| an opinion on it

Aah, and this sums up this entire thread. "The name sucks. I haven't
used it. It isn't pink enough."
| - tarball management (fetching via users tool of choice be it from
| the web or according to a file list from a named media (e.g. DVD or a
| tape), mirror handling etc.)
| - profile management (keeping the on disk representation apart from
| the way the dependency resolver gets the information)
| - package management (dependency resolver, ect.)
| - package installer (install files or create binary packages, may the
| target be .tbz2, .deb or .rpm)
| 
| and implement them as independent tools, so we can easly exchange one
| for the other, if there is a superior one, instead having to throw
| everything away?!

Nice idea in theory. In reality, Portage is a big incestuous mess and
can't have that kind of change made to it, and defining such an
interface between package manager parts would take considerably more
time and code than just rewriting the whole thing. Having said that,
you can swap around pretty much any component of Paludis, since it's
proper modular code -- Kugelfang has a mostly working implementation of
a CRAN repository, for example.

| I don't think it would be beneficial in the long run, if the outcome
| would be that Gentoo divides into groups using different package
| managers.

I strongly suspect that in the long run one package manager will stand
out as by far the best solution. Whichever one this ends up being, it
will be one of the modular rewrites that makes future changes quite a
bit easier.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Carsten Lohrke]

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

On Wednesday 17 May 2006 15:50, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 01:58:02 +0200 Carsten Lohrke <carlo@gentoo.org>
>
> wrote:
> | I haven't had a look at Paludis (the name sucks as much as the name
> | eselect had, before it was named eselect, btw.) yet, so I don't have
> | an opinion on it
>
> Aah, and this sums up this entire thread. "The name sucks. I haven't
> used it. It isn't pink enough."

Please do not mix up the flaming between you and Diego with my email. Yes, it 
isn't pink enough and I don't like your ponytail either. :p

> Nice idea in theory. In reality, Portage is a big incestuous mess and
> can't have that kind of change made to it

The former yes, the latter statement is questionable.

> , and defining such an 
> interface between package manager parts would take considerably more
> time and code than just rewriting the whole thing.

That won't mean you face the same situation at one point again, so you likely 
have to spent the same or even more amount of time, just over a longer time 
frame.

> Having said that, 
> you can swap around pretty much any component of Paludis, since it's
> proper modular code -- Kugelfang has a mostly working implementation of
> a CRAN repository, for example.

Doesn't sound like independent runtime components, as I am proposing.


Carsten

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 16:21:13 +0200 Carsten Lohrke <carlo@gentoo.org>
wrote:
| > Nice idea in theory. In reality, Portage is a big incestuous mess
| > and can't have that kind of change made to it
| 
| The former yes, the latter statement is questionable.

Not really. It's why everyone is busy rewriting Portage. The code
simply isn't modular enough to make ripping out any particular
component viable.

| > , and defining such an 
| > interface between package manager parts would take considerably more
| > time and code than just rewriting the whole thing.
| 
| That won't mean you face the same situation at one point again, so
| you likely have to spent the same or even more amount of time, just
| over a longer time frame.

And no matter how many times people end up rewriting things, doing a
generic future-proof cross-language interface that supports everything
that *might* be done in the future is going to take so long that it
will never actually get written.

| > Having said that, 
| > you can swap around pretty much any component of Paludis, since it's
| > proper modular code -- Kugelfang has a mostly working
| > implementation of a CRAN repository, for example.
| 
| Doesn't sound like independent runtime components, as I am proposing.

It's compile time at present, simply because no-one considers it worth
the effort of screwing around with .so files until it's really really
necessary.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[George Prowse]

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

Why risk anything by changing the tree to suit the package? It just seems
like asking for trouble. The overlay ability is there for a reason. Paludis
isn't being used and should be kept out of the sphere of users use until it
is usable, wont break systems and is trustworthy enough to be near the tree

[-- Attachment #2: Type: text/html, Size: 327 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 15:25:08 +0100
"George Prowse" <cokehabit@gmail.com> wrote:

> Why risk anything by changing the tree to suit the package? 

We're not risking anything, except upsetting a few people. We're not
changing anything either, just adding a few files.

> It just
> seems like asking for trouble. The overlay ability is there for a
> reason.

Yes, to work around a lack of multiple repository support. It's not
there to try to mix profiles between repositories.

> Paludis isn't being used and should be kept out of the sphere
> of users use until it is usable, wont break systems and is
> trustworthy enough to be near the tree

It is, it is, it won't unless the user screws up (as with, say,
Portage), and it is.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[George Prowse]

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

On 17/05/06, Stephen Bennett <spb@gentoo.org> wrote:
>
> On Wed, 17 May 2006 15:25:08 +0100
> "George Prowse" <cokehabit@gmail.com> wrote:
>
> > Why risk anything by changing the tree to suit the package?
>
> We're not risking anything, except upsetting a few people. We're not
> changing anything either, just adding a few files.


Any adding is increasing the risk.

> It just
> > seems like asking for trouble. The overlay ability is there for a
> > reason.
>
> Yes, to work around a lack of multiple repository support. It's not
> there to try to mix profiles between repositories.


Surely then it would be better to work on a comprimise for the sake of
Gentoo rather than paludis. Horse before the cart.

> Paludis isn't being used and should be kept out of the sphere
> > of users use until it is usable, wont break systems and is
> > trustworthy enough to be near the tree
>
> It is, it is, it won't unless the user screws up (as with, say,
> Portage), and it is.


So good working practice is to introduce a variable where breakages could
come from two directions rather than stick with what works? Let the project
mature before asking for changes from the Gentoo side.

[-- Attachment #2: Type: text/html, Size: 1879 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 15:57:51 +0100
"George Prowse" <cokehabit@gmail.com> wrote:

> Any adding is increasing the risk.

No it's not. The only risk comes from the user choosing an
inappropriate profile for his system, which is already present.

> So good working practice is to introduce a variable where breakages
> could come from two directions rather than stick with what works? Let
> the project mature before asking for changes from the Gentoo side.

That paragraph makes no sense. I don't see what you're trying to say.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[George Prowse]

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

On 17/05/06, Stephen Bennett <spb@gentoo.org> wrote:
>
> On Wed, 17 May 2006 15:57:51 +0100
> "George Prowse" <cokehabit@gmail.com> wrote:
>
> > So good working practice is to introduce a variable where breakages
> > could come from two directions rather than stick with what works? Let
> > the project mature before asking for changes from the Gentoo side.
>
> That paragraph makes no sense. I don't see what you're trying to say.
>

What it is saying is why introduce anything or change anything just for your
package? Why introduce the possibility of a problem on either the program or
the tree side?

So far you have failed to give one proper reason for why a change should be
made.

[-- Attachment #2: Type: text/html, Size: 1192 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 17:37:07 +0100
"George Prowse" <cokehabit@gmail.com> wrote:

> What it is saying is why introduce anything or change anything just
> for your package? Why introduce the possibility of a problem on
> either the program or the tree side?

Profile changes are made all the time for the benefit of a single
package in the tree. From that point of view this is no different.

> So far you have failed to give one proper reason for why a change
> should be made.

Sure I have. Try reading the initial mail.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Tue, 2006-05-16 at 23:22 +0100, Stephen Bennett wrote:
> > 1) Is bugsy ready for this, with appropriate categories in place?
> 
> Paludis-related bugs can be marked as invalid and the user directed to
> Paludis' bug tracker on berlios.de. Alternatively, if our friendly
> Bugzilla admins want to create categories I won't complain. I don't see
> a need for it though.

This is the exact reason why I would disagree with having this profile
in the tree.  It *is* going to cause more work for bug-wranglers, no
matter how many places you put warnings and notices.  If the profile is
*not* in the portage tree, people won't file bugs in our bugzilla.  If
the profile *is* in the portage tree, then users will file bugs in our
bugzilla.  Anything that we add to the tree, we are expected to provide
a reasonable level of support for maintaining.

If there is a bug in Paludis, since the package *is* in our tree, users
can file bugs in our bugzilla.  Now, you might mark them as INVALID
(which is wrong, btw) or UPSTREAM (which is right), but *somebody* has
to take the time to look at the bug, determine that it is a Paludis bug,
then do the work to UPSTREAM it.  Proper usage of UPSTREAM means
actually *filing* a bug upstream, not just pushing it off on the user,
though this isn't used nearly as much in practice as it should be.

A profile is an even more problematic affair, as it has an even
longer-standing assumption that they are 100% supported by Gentoo.

Paludis supports multiple repositories correctly, right?  So why is it a
big deal to provide the profiles in their own overlay/repository?  I
haven't heard a good reason why the profiles need to be in the portage
tree.  I'm not saying I am against it being added so much as I haven't
heard a single compelling reason for doing it, and quite a few
compelling reasons why *not* to do it, mainly support-related.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Patrick McLean]

Chris Gianelloni wrote:
> On Tue, 2006-05-16 at 23:22 +0100, Stephen Bennett wrote:
> 
> This is the exact reason why I would disagree with having this profile
> in the tree.  It *is* going to cause more work for bug-wranglers, no
> matter how many places you put warnings and notices.  If the profile is
> *not* in the portage tree, people won't file bugs in our bugzilla.  If
> the profile *is* in the portage tree, then users will file bugs in our
> bugzilla.  Anything that we add to the tree, we are expected to provide
> a reasonable level of support for maintaining.
> 

Last time I checked, we don't support *everything* in the tree, for
example everything in package.mask and/or keyworded -* is considered
unsupported (or are you trying to tell me that
sys-devel/gcc-4.2.0_alpha20060513 is officially supported).

> If there is a bug in Paludis, since the package *is* in our tree, users
> can file bugs in our bugzilla.  Now, you might mark them as INVALID
> (which is wrong, btw) or UPSTREAM (which is right), but *somebody* has
> to take the time to look at the bug, determine that it is a Paludis bug,
> then do the work to UPSTREAM it.  Proper usage of UPSTREAM means
> actually *filing* a bug upstream, not just pushing it off on the user,
> though this isn't used nearly as much in practice as it should be.
> 
> A profile is an even more problematic affair, as it has an even
> longer-standing assumption that they are 100% supported by Gentoo.

Deprecated profiles are considered unsupported, as are most of the
gentoo-alt profiles. Also most arches have development profiles which
are considered unsupported (on amd64 we add a profile.bashrc that dies
unless something like I_WANT_TO_BREAK_MY_SYSTEM=1 is set).

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Wednesday 17 May 2006 16:17, Patrick McLean wrote:
> Deprecated profiles are considered unsupported, as are most of the
> gentoo-alt profiles
default-bsd *is* supported. Gentoo/FreeBSD project (that would be myself) 
takes care of all the bugs related as fast as  possible. The unsupported 
Gentoo/Alt profiles are in the Gentoo/Alt overlay.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Kevin F. Quinn]

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

On Wed, 17 May 2006 10:17:16 -0400
Patrick McLean <chutzpah@gentoo.org> wrote:

> Last time I checked, we don't support *everything* in the tree, for
> example everything in package.mask and/or keyworded -* is considered
> unsupported (or are you trying to tell me that
> sys-devel/gcc-4.2.0_alpha20060513 is officially supported).

Where gcc-4.2.0_alpha is concerned, the important thing is that while
it is not supported at the moment, it _will_ be supported in the
future.  The same is not being said for paludis at the moment - the
paludis people are not claiming paludis will become official; I think
everyone would agree it's too early to be thinking about that now.

> Deprecated profiles are considered unsupported,

The key point there is that they're deprecated - deprecated means "will
be removed". That means anyone using them should be aware they will be
removed at some point.  Again, that's not what Paludis is about (if it
was, the paludis team wouldn't be asking to put stuff in the tree!).

> as are most of the gentoo-alt profiles.
(see Flameeyes response)

> Also most arches have development profiles which
> are considered unsupported (on amd64 we add a profile.bashrc that dies
> unless something like I_WANT_TO_BREAK_MY_SYSTEM=1 is set).

However these are development profiles for actual supported profiles -
in other words the stuff in the development profiles is expected to
become supported at some point (either by inclusion or rejection).
Again, not the case with paludis as it is currently being proposed.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 10:17 -0400, Patrick McLean wrote:
> Last time I checked, we don't support *everything* in the tree, for
> example everything in package.mask and/or keyworded -* is considered
> unsupported (or are you trying to tell me that
> sys-devel/gcc-4.2.0_alpha20060513 is officially supported).

Yes, it is supported.  Ask Halcy0n.  If you file a bug, he'll try to fix
it.  To me, that's a "reasable level of support".

Notice I said *nothing* about *how* something should be supported.
Please don't try to interject your own thoughts into my words.

> > If there is a bug in Paludis, since the package *is* in our tree, users
> > can file bugs in our bugzilla.  Now, you might mark them as INVALID
> > (which is wrong, btw) or UPSTREAM (which is right), but *somebody* has
> > to take the time to look at the bug, determine that it is a Paludis bug,
> > then do the work to UPSTREAM it.  Proper usage of UPSTREAM means
> > actually *filing* a bug upstream, not just pushing it off on the user,
> > though this isn't used nearly as much in practice as it should be.
> > 
> > A profile is an even more problematic affair, as it has an even
> > longer-standing assumption that they are 100% supported by Gentoo.
> 
> Deprecated profiles are considered unsupported, as are most of the
> gentoo-alt profiles. Also most arches have development profiles which
> are considered unsupported (on amd64 we add a profile.bashrc that dies
> unless something like I_WANT_TO_BREAK_MY_SYSTEM=1 is set).

Yeah, and amd64 doesn't do that anymore because it broke repoman and I
had it removed.  Also, even those profiles were still supported
in-so-far as you accepted bug reports (with patches) that resolved
issues with the profile.  I personally have worked with several amd64
team members to fix bugs in these "unsupported" profiles in the past.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

[gentoo-dev] Re: Paludis and Profiles

[Duncan]

Patrick McLean <chutzpah@gentoo.org> posted 446B306C.5040901@gentoo.org,
excerpted below, on  Wed, 17 May 2006 10:17:16 -0400:

> Deprecated profiles are considered unsupported, as are most of the
> gentoo-alt profiles. Also most arches have development profiles which
> are considered unsupported (on amd64 we add a profile.bashrc that dies
> unless something like I_WANT_TO_BREAK_MY_SYSTEM=1 is set).

...  And the proposal included a deprecated file.  By that definition,
therefore, the profile would be unsupported, and the point you were
making disappears.

-- 
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: Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 15:57:39 +0000 (UTC) "Duncan"
<1i5t5.duncan@cox.net> wrote:
| Patrick McLean <chutzpah@gentoo.org> posted
| 446B306C.5040901@gentoo.org, excerpted below, on  Wed, 17 May 2006
| 10:17:16 -0400:
| 
| > Deprecated profiles are considered unsupported, as are most of the
| > gentoo-alt profiles. Also most arches have development profiles
| > which are considered unsupported (on amd64 we add a profile.bashrc
| > that dies unless something like I_WANT_TO_BREAK_MY_SYSTEM=1 is set).
| 
| ...  And the proposal included a deprecated file.  By that definition,
| therefore, the profile would be unsupported, and the point you were
| making disappears.

To work around Portage, not because the profile is deprecated in the
conventional sense.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 09:58:41 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| Paludis supports multiple repositories correctly, right?  So why is
| it a big deal to provide the profiles in their own
| overlay/repository?  I haven't heard a good reason why the profiles
| need to be in the portage tree.  I'm not saying I am against it being
| added so much as I haven't heard a single compelling reason for doing
| it, and quite a few compelling reasons why *not* to do it, mainly
| support-related.

We'd have to extend the parent file to support something like:

$(location_of_repository_named gentoo)/profiles/default-linux/etc

since a) profiles are per-repository and b) we don't want to copy the
whole Gentoo profile structure.

Now, whilst this change could be useful, it's going to cause a huge
incompatibility with Portage... So unless someone can come up with a
solution that won't...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Christian Hartmann]

> With respect to the "hey support omg!" comments i say stick a big fat
> README about being an experimental profile or something like that and
> that's it. Usually bug reports require "emerge --info" so it'll be easy
> to flag invalid ones anyway.

Well. Marking a bug invalid doesn't make the real problem go away... but the 
users.

-- 
Christian Hartmann
http://www.gentoo.org/~ian/

PGP Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865
Key fingerprint = 4544 EC0C BAE4 216F 5981  7F95 2154 E5EE 692A 4865

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Matthijs van der Vleuten]

On 5/17/06, Christian Hartmann <ian@gentoo.org> wrote:
> > With respect to the "hey support omg!" comments i say stick a big fat
> > README about being an experimental profile or something like that and
> > that's it. Usually bug reports require "emerge --info" so it'll be easy
> > to flag invalid ones anyway.
>
> Well. Marking a bug invalid doesn't make the real problem go away... but the
> users.

I'd say that's exactly the intention of INVALID. If I were to file,
say, a bug in GCC at Gentoo's Bugzilla instead of GCC's, it would be
marked INVALID. (Unless, of course, the bug is caused by Gentoo's
patches.)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Donnie Berkholz]

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

Matthijs van der Vleuten wrote:
> On 5/17/06, Christian Hartmann <ian@gentoo.org> wrote:
>> > With respect to the "hey support omg!" comments i say stick a big fat
>> > README about being an experimental profile or something like that and
>> > that's it. Usually bug reports require "emerge --info" so it'll be easy
>> > to flag invalid ones anyway.
>>
>> Well. Marking a bug invalid doesn't make the real problem go away...
>> but the
>> users.
> 
> I'd say that's exactly the intention of INVALID. If I were to file,
> say, a bug in GCC at Gentoo's Bugzilla instead of GCC's, it would be
> marked INVALID. (Unless, of course, the bug is caused by Gentoo's
> patches.)

Actually it should be marked UPSTREAM. But we're getting a bit offtopic
here.

Thanks,
Donnie


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

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 09:30 +0200, Matthijs van der Vleuten wrote:
> On 5/17/06, Christian Hartmann <ian@gentoo.org> wrote:
> > > With respect to the "hey support omg!" comments i say stick a big fat
> > > README about being an experimental profile or something like that and
> > > that's it. Usually bug reports require "emerge --info" so it'll be easy
> > > to flag invalid ones anyway.
> >
> > Well. Marking a bug invalid doesn't make the real problem go away... but the
> > users.
> 
> I'd say that's exactly the intention of INVALID. If I were to file,
> say, a bug in GCC at Gentoo's Bugzilla instead of GCC's, it would be
> marked INVALID. (Unless, of course, the bug is caused by Gentoo's
> patches.)

No.  It should be marked as UPSTREAM and a bug should be filed in GCC's
bug tracker or the authors emailed if there's no tracker.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Mark Loeser]

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

Matthijs van der Vleuten <zr40.nl@gmail.com> said:
> I'd say that's exactly the intention of INVALID. If I were to file,
> say, a bug in GCC at Gentoo's Bugzilla instead of GCC's, it would be
> marked INVALID. (Unless, of course, the bug is caused by Gentoo's
> patches.)

No, I would get a testcase for the bug and file it upstream.  The only
bugs I've marked invalid are for the testing versions of GCC.

But, this is entirely off topic.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

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

Re: [gentoo-dev] Paludis and Profiles

[Robin H. Johnson]

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

On Tue, May 16, 2006 at 04:15:49PM +0100, Stephen Bennett wrote:
> Comments?
I have no objections to the concept - I would however like very through
testing before it's actually committed.

Could you please submit the profile as a patch to the mailing list, 
thus allowing detractors to test cases that they believe it may break.
- If it breaks them, then something needs to be done.
- If it doesn't break them, then they have no reasonable grounds for rejecting the patch.

I myself have a few cases I'd like to test, on fringe cases of portage
behavior.

Backwards compatibility is the most important thing with the core
portions of the tree - new functionality must always be introduced in
such a way that the existing majority does not experience breakage -
because they'll make somebodies life hell.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Paludis and Profiles

[Daniel Drake]

Stephen Bennett wrote:
> If noone has any strong reasonable objections, I'd like to add a
> Paludis profile to the tree. 

I think that this should be the decision of the Portage developers. If 
there is any burden other than the points you mentioned, it directly or 
indirectly falls on them.

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 20:10:16 +0100 Daniel Drake <dsd@gentoo.org> wrote:
| Stephen Bennett wrote:
| > If noone has any strong reasonable objections, I'd like to add a
| > Paludis profile to the tree. 
| 
| I think that this should be the decision of the Portage developers.
| If there is any burden other than the points you mentioned, it
| directly or indirectly falls on them.

Adding a new profile doesn't affect Portage unless Portage is told to
use that profile. And anyone telling Portage to use *any* invalid
profile is going to be in for a shock.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Daniel Drake]

Ciaran McCreesh wrote:
> Adding a new profile doesn't affect Portage unless Portage is told to
> use that profile. And anyone telling Portage to use *any* invalid
> profile is going to be in for a shock.
> 

I was more thinking along the lines of that there might be a lot of 
confusion if Paludis and Portage have varying feature sets, and do not 
maintain total ebuild compatibility both ways. We all know how keen our 
users are to try new stuff...

Daniel

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Tue, 16 May 2006 21:56:10 +0100 Daniel Drake <dsd@gentoo.org> wrote:
| Ciaran McCreesh wrote:
| > Adding a new profile doesn't affect Portage unless Portage is told
| > to use that profile. And anyone telling Portage to use *any* invalid
| > profile is going to be in for a shock.
| 
| I was more thinking along the lines of that there might be a lot of 
| confusion if Paludis and Portage have varying feature sets, and do
| not maintain total ebuild compatibility both ways. We all know how
| keen our users are to try new stuff...

A large part of why Paludis exists is because I and several others were
sick of waiting for three years for Portage to provide certain basic
features.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Simon Stelling]

Ciaran McCreesh wrote:
> A large part of why Paludis exists is because I and several others were
> sick of waiting for three years for Portage to provide certain basic
> features.

Which is really what this whole thread is all about... Sorry for being an ass, 
but could we *maybe* stop the constant portage bashing and turn this into an 
on-topic discussion?

Thanks.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Wernfried Haas]

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

This is not only about adding a profile, but if paludis is officially
supported by being in the tree and profiles, fixes for paludis get
into the tree etc, this sounds like paludis is a Gentoo project and users
will expect it to work and be supported. They will be allowed to ask
questions about something not working with paludis on the forums,
mailing lists, on irc etc without being off-topic.
So far and with respect to other distributions (like e.g. Vida,
Kororaa or whatever they were called) a rule of thumb was:
A Gentoo system uses the official portage tree, was installed using
the Gentoo installation guide using Gentoo stages, etc - and which was
rather implicit - using portage as package manager. As far i
understand it paludis differs from that in many ways.
So before the package manager gets optional and we support something
quite different we really should figure out what we consider a Gentoo
installation. 

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: 191 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Wernfried Haas]

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

On Tue, May 16, 2006 at 10:16:32PM +0200, Wernfried Haas wrote:
> This is not only about adding a profile, but if paludis is officially
> supported by being in the tree and profiles, fixes for paludis get
> into the tree etc, this sounds like paludis is a Gentoo project and users
> will expect it to work and be supported. They will be allowed to ask
> questions about something not working with paludis on the forums,
> mailing lists, on irc etc without being off-topic.
> So far and with respect to other distributions (like e.g. Vida,
> Kororaa or whatever they were called) a rule of thumb was:
> A Gentoo system uses the official portage tree, was installed using
> the Gentoo installation guide using Gentoo stages, etc - and which was
> rather implicit - using portage as package manager. As far i
> understand it paludis differs from that in many ways.
> So before the package manager gets optional and we support something
> quite different we really should figure out what we consider a Gentoo
> installation. 

Does the lack of responses mean everyone agrees to my point? We really
should figure that stuff out before we start integrating an externally
written package manager we have no influence on whatsoever - otherwise 
it would just be fair to do everything any other Gentoo based
distribution demands from us as well.

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: 191 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Roy Marples]

On Wednesday 17 May 2006 10:23, Wernfried Haas wrote:
> On Tue, May 16, 2006 at 10:16:32PM +0200, Wernfried Haas wrote:
> > This is not only about adding a profile, but if paludis is officially
> > supported by being in the tree and profiles, fixes for paludis get
> > into the tree etc, this sounds like paludis is a Gentoo project and users
> > will expect it to work and be supported. They will be allowed to ask
> > questions about something not working with paludis on the forums,
> > mailing lists, on irc etc without being off-topic.
> > So far and with respect to other distributions (like e.g. Vida,
> > Kororaa or whatever they were called) a rule of thumb was:
> > A Gentoo system uses the official portage tree, was installed using
> > the Gentoo installation guide using Gentoo stages, etc - and which was
> > rather implicit - using portage as package manager. As far i
> > understand it paludis differs from that in many ways.
> > So before the package manager gets optional and we support something
> > quite different we really should figure out what we consider a Gentoo
> > installation.

I see no difference between this and other external projects which have an 
impact on the tree, like say gcc. If a gentoo dev puts an alpha of gcc in and 
it's package masked and stuff, then I expect devs that put Paludis in the 
tree to provide a similar level of support.

I will happily provide support for baselayout and what I put it in the tree, 
but I'll provide exactly the same level of support for Paludis as I do for 
Portage - nothing.

>
> Does the lack of responses mean everyone agrees to my point? We really
> should figure that stuff out before we start integrating an externally
> written package manager we have no influence on whatsoever - otherwise
> it would just be fair to do everything any other Gentoo based
> distribution demands from us as well.

Tell you what, you figure out the internals of baselayout or we'll remove it 
from the tree. I think a few Gentoo dev's know Paludis internals enough to 
support it.

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo/Linux Developer (baselayout, networking)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Wernfried Haas]

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

On Wed, May 17, 2006 at 11:42:14AM +0100, Roy Marples wrote:
> On Wednesday 17 May 2006 10:23, Wernfried Haas wrote:
> > On Tue, May 16, 2006 at 10:16:32PM +0200, Wernfried Haas wrote:
> > > This is not only about adding a profile, but if paludis is officially
> > > supported by being in the tree and profiles, fixes for paludis get
> > > into the tree etc, this sounds like paludis is a Gentoo project and users
> > > will expect it to work and be supported. They will be allowed to ask
> > > questions about something not working with paludis on the forums,
> > > mailing lists, on irc etc without being off-topic.
> > > So far and with respect to other distributions (like e.g. Vida,
> > > Kororaa or whatever they were called) a rule of thumb was:
> > > A Gentoo system uses the official portage tree, was installed using
> > > the Gentoo installation guide using Gentoo stages, etc - and which was
> > > rather implicit - using portage as package manager. As far i
> > > understand it paludis differs from that in many ways.
> > > So before the package manager gets optional and we support something
> > > quite different we really should figure out what we consider a Gentoo
> > > installation.
> 
> I see no difference between this and other external projects which have an 
> impact on the tree, like say gcc. If a gentoo dev puts an alpha of gcc in and 
> it's package masked and stuff, then I expect devs that put Paludis in the 
> tree to provide a similar level of support.

So you consider a system using paludis instead of portage still a
generic Gentoo installation, which we as Gentoo support in all ways?
We may have a different understanding of the term "support" - in my
eyes that doesn't mean it's just not broken, but we also give users
support, allow them to ask questions and don't mark bugreports with
INVALID. This also includes forums, irc, lists, writing docs, etc.

So far we've been moving stuff out of the Gentoo forums to Off the
Wall if people were using fancy overlays of their Gentoo based
distribution or systems built with non official stages - so what do we
do with systems using another package manager than portage?

> > Does the lack of responses mean everyone agrees to my point? We really
> > should figure that stuff out before we start integrating an externally
> > written package manager we have no influence on whatsoever - otherwise
> > it would just be fair to do everything any other Gentoo based
> > distribution demands from us as well.
> 
> Tell you what, you figure out the internals of baselayout or we'll remove it 
> from the tree. I think a few Gentoo dev's know Paludis internals enough to 
> support it.

So because a few developers know its internals we can and do support it (in
all ways as stated above)? That's exactly the issue i want to have
answered clearly, sorry if it was a misunderstanding before.

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: 191 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Thomas Cort]

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

On Wed, 17 May 2006 11:23:19 +0200
Wernfried Haas <amne@gentoo.org> wrote:
> We really should figure that stuff out before we start integrating an
> externally written package manager we have no influence on whatsoever

No influence? Last I checked, the number of Gentoo developers on the project out numbered the number of non-Gentoo developers 5 to 1. See http://paludis.berlios.de/Authors.html

-- 
,__,       +----------+  |  Thomas Cort <tcort@gentoo.org>
(oo)____   |SAVE LARRY|  |  Gentoo Linux Developer
(__)    )\ +----------+  |  alpha, amd64, sound
   ||--|| *      |       |  http://dev.gentoo.org/~tcort


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

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Wednesday 17 May 2006 14:02, Thomas Cort wrote:
> No influence? Last I checked, the number of Gentoo developers on the
> project out numbered the number of non-Gentoo developers 5 to 1. See
> http://paludis.berlios.de/Authors.html
Uh we don't _work_ for Gentoo. I'm the sole author of unieject and RubyTag++, 
but they both has nothing to do with Gentoo (I even moved out rubytag++ from 
my dev space on woodpecker to move it on my own server).

Gentoo != Gentoo Developers (only)

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 11:23:19 +0200 Wernfried Haas <amne@gentoo.org>
wrote:
| We really should figure that stuff out before we start integrating an
| externally written package manager we have no influence on whatsoever

How much influence does your typical Gentoo developer or user have over
the development of Portage? Please consider long-standing feature
requests such as :slot and [use] deps in your answer.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Wernfried Haas]

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

On Wed, May 17, 2006 at 06:32:38PM +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 11:23:19 +0200 Wernfried Haas <amne@gentoo.org>
> wrote:
> | We really should figure that stuff out before we start integrating an
> | externally written package manager we have no influence on whatsoever
> 
> How much influence does your typical Gentoo developer or user have over
> the development of Portage? Please consider long-standing feature
> requests such as :slot and [use] deps in your answer.

That's not the point as i wasn't talking about single developers but
Gentoo as an organisation. Paludis is not in any way under Gentoo's
control. If the paludis devs decide to change the license for paludis
1.0 to a commercial one, Gentoo would be unable do anything about it
(except fork the last GPLed version). If the paludis devs decide to
terminate all ricers with RTFM, Gentoo can't do anything about it. I
guess the list could be continued with other examples.
I'm not saying the paludis devs may do such a thing, but they could
and Gentoo couldn't do anything about it.
As long a project is within Gentoo, every developer does at least have
some influence, be it by voting the council or whatsoever.

As for your long standing feature requests, this has nothing to do
with the issue, unless you're trying to bash the portage team, which
has nothing to do with this thread.

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: 191 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 20:11:57 +0200 Wernfried Haas <amne@gentoo.org>
wrote:
| That's not the point as i wasn't talking about single developers but
| Gentoo as an organisation. Paludis is not in any way under Gentoo's
| control. If the paludis devs decide to change the license for paludis
| 1.0 to a commercial one, Gentoo would be unable do anything about it
| (except fork the last GPLed version).

And what if the Bash licence changes? Or the Python licence?

| If the paludis devs decide to
| terminate all ricers with RTFM, Gentoo can't do anything about it. I
| guess the list could be continued with other examples.
| I'm not saying the paludis devs may do such a thing, but they could
| and Gentoo couldn't do anything about it.

Yes, and the Bash developers *could* decide to make new Bash versions
print out an ASCII art diagram of a BSD daemon sporking Larry.

| As long a project is within Gentoo, every developer does at least have
| some influence, be it by voting the council or whatsoever.

And just what do you think would happen if the council were to demand
that Portage implements a new feature?

| As for your long standing feature requests, this has nothing to do
| with the issue, unless you're trying to bash the portage team, which
| has nothing to do with this thread.

Sure it does. It's a perfect demonstration that the needs and demands
of Gentoo have no influence over what happens to Portage.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Wernfried Haas]

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

On Wed, May 17, 2006 at 08:34:52PM +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 20:11:57 +0200 Wernfried Haas <amne@gentoo.org>
> wrote:
> | That's not the point as i wasn't talking about single developers but
> | Gentoo as an organisation. Paludis is not in any way under Gentoo's
> | control. If the paludis devs decide to change the license for paludis
> | 1.0 to a commercial one, Gentoo would be unable do anything about it
> | (except fork the last GPLed version).
> 
> And what if the Bash licence changes? Or the Python licence?

That's a bit different as these are dependencies. Paludis has those too.
Let's concentrate on the package manager - and as said there is no way
for Gentoo to have any influence on paludis.

> | If the paludis devs decide to
> | terminate all ricers with RTFM, Gentoo can't do anything about it. I
> | guess the list could be continued with other examples.
> | I'm not saying the paludis devs may do such a thing, but they could
> | and Gentoo couldn't do anything about it.
> 
> Yes, and the Bash developers *could* decide to make new Bash versions
> print out an ASCII art diagram of a BSD daemon sporking Larry.

Please don't turn this in another pink elephant argument.

> | As long a project is within Gentoo, every developer does at least have
> | some influence, be it by voting the council or whatsoever.
> 
> And just what do you think would happen if the council were to demand
> that Portage implements a new feature?

Depends - but more than if it demands a new paludis feature.

> | As for your long standing feature requests, this has nothing to do
> | with the issue, unless you're trying to bash the portage team, which
> | has nothing to do with this thread.
> 
> Sure it does. It's a perfect demonstration that the needs and demands
> of Gentoo have no influence over what happens to Portage.

Sorry, but all i see is bashing portage, and i don't really like it.

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: 191 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Christian Birchinger]

On Wed, May 17, 2006 at 08:11:57PM +0200, Wernfried Haas wrote:
> On Wed, May 17, 2006 at 06:32:38PM +0100, Ciaran McCreesh wrote:
> 
> That's not the point as i wasn't talking about single developers but
> Gentoo as an organisation. Paludis is not in any way under Gentoo's
> control. If the paludis devs decide to change the license for paludis
> 1.0 to a commercial one, Gentoo would be unable do anything about it
> (except fork the last GPLed version). If the paludis devs decide to
> terminate all ricers with RTFM, Gentoo can't do anything about it. I
> guess the list could be continued with other examples.
> I'm not saying the paludis devs may do such a thing, but they could
> and Gentoo couldn't do anything about it.
> As long a project is within Gentoo, every developer does at least have
> some influence, be it by voting the council or whatsoever.
> 
> As for your long standing feature requests, this has nothing to do
> with the issue, unless you're trying to bash the portage team, which
> has nothing to do with this thread.

Then you remove the profile just like you would remove any piece
of software where the license is unacceptable.

The arguments are getting more and more "creative". It's almost
like asking what we will do when gcc turns into a commercial
product.
Please try to stay realistic and don't invent strange new
theoretical problems.

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

Re: [gentoo-dev] Paludis and Profiles

[Wernfried Haas]

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

On Wed, May 17, 2006 at 11:13:16PM +0200, Christian Birchinger wrote:
> Then you remove the profile just like you would remove any piece
> of software where the license is unacceptable.

Please look a bit up in the thread, my point was not only the profile
but integrating a package manager we have no control over.

> The arguments are getting more and more "creative". It's almost
> like asking what we will do when gcc turns into a commercial
> product.

The package manager is a central piece, if we ever want to change our
package manager we really should think about problems like that.

> Please try to stay realistic and don't invent strange new
> theoretical problems.

Better safe then sorry.

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: 191 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 22:53:47 +0200
Wernfried Haas <amne@gentoo.org> wrote:

> > The arguments are getting more and more "creative". It's almost
> > like asking what we will do when gcc turns into a commercial
> > product.
> 
> The package manager is a central piece, if we ever want to change our
> package manager we really should think about problems like that.

So's the toolchain.

> > Please try to stay realistic and don't invent strange new
> > theoretical problems.
> 
> Better safe then sorry.

Better to stick to reality than invent pink elephants to back up a
completely baseless assertion.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Wernfried Haas]

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

On Wed, May 17, 2006 at 11:17:39PM +0100, Stephen Bennett wrote:
> Better to stick to reality than invent pink elephants to back up a
> completely baseless assertion.

Someone should rewrite Godwin's law to include pink elephants. This
subthread has gone beyond usefulness. Sorry everyone for the noise and
me being a part of this.

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: 191 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Christian Birchinger]

On Wed, May 17, 2006 at 10:53:47PM +0200, Wernfried Haas wrote:
> On Wed, May 17, 2006 at 11:13:16PM +0200, Christian Birchinger wrote:
> > Then you remove the profile just like you would remove any piece
> > of software where the license is unacceptable.
> 
> Please look a bit up in the thread, my point was not only the profile
> but integrating a package manager we have no control over.
> 
> > The arguments are getting more and more "creative". It's almost
> > like asking what we will do when gcc turns into a commercial
> > product.
> 
> The package manager is a central piece, if we ever want to change our
> package manager we really should think about problems like that.
> 
> > Please try to stay realistic and don't invent strange new
> > theoretical problems.
> 
> Better safe then sorry.
> 

It's GPL-2, no? If the license changes before it's a full
replacment ... remove the profile. If it changes after it
became the standard ... fork it.

I think at the moment there's no plan to replace anything.
There was a simple request to add a profile to make it easier
for some people to develop something. We can talk about
replacing anything later, when there are more intrusive
requests like changing all ebuilds etc.

I honestly think people are just bringing up the wildest things
just to find another reason to say "no". It Looks a bit like
even good ideas and project have no chance when they come from
"the wrong people".

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

Re: [gentoo-dev] Paludis and Profiles

[Patrick McLean]

Christian Birchinger wrote:
> 
> I honestly think people are just bringing up the wildest things
> just to find another reason to say "no". It Looks a bit like
> even good ideas and project have no chance when they come from
> "the wrong people".
> 
Thank you, you just summed up what I have been thinking about this
thread. It seems like people are really looking for whatever possible
technical reasons they to be able to say "no" simply because they don't
like certain members of the paludis team.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 23:34, Christian Birchinger wrote:
> I think at the moment there's no plan to replace anything.
> There was a simple request to add a profile to make it easier
> for some people to develop something. We can talk about
> replacing anything later, when there are more intrusive
> requests like changing all ebuilds etc.

What is then the purpose of paludis. Is its purpose to create a package 
manager for a new distro, and the paludis team would like to use gentoo 
as a testing ground?

Or is the purpose of the paludis team to have paludis be an alternative to 
portage. In that case it should respect portage, and make efforts to 
follow the standard that portage sets.
>
> I honestly think people are just bringing up the wildest things
> just to find another reason to say "no". It Looks a bit like
> even good ideas and project have no chance when they come from
> "the wrong people".

If I only wanted to say No, I would not have needed this many words. Many 
of what I said applies just as well for pkgcore as for paludis (or any 
other package manager). 

What I have done is stated:
- Why paludis accomodations are too early at this moment
- Why package managers should not have their own profiles
- What categories of package managers can exist (candidate replacement,
  secondary, third-party)
- That there can only one primary package manager
- What requirements exist for a secondary package manager
- What requirements exist for a candidate replacement package manager
- How paludis developers could enhance paludis such that it could be
  considered as a candidate portage replacement.
- That the decision to replace portage should be made explicitly and
  should not be forced upon the project by packages in the tree requiring
  the candidate replacement package manager
- That accomodations for a package manager can only be made for candidate
  package manager or for a secondary package manager (that must encertain
  full portage compatibility).

Let's give some examples of what candidate package managers and secondary 
package managers can do.

One of the biggest issues for amd64 is the fact that packages can not be 
installed for particular architectures or in paralel. An alternative 
package manager could offer a way that while allowing each architecture 
to be installed separately, it merges the files into one package and 
maintains separate files that record which subpackage which file belongs 
to. This way portage can remove the package, see that it's there and even 
verify the contents. It only can not itself provide multi architecture 
installation.

Another thing is reverse dependencies. This is missing from portage, but a 
feature that could well be implemented independent of the on-disk system.

Aditional package formats could be supported. The only restriction is that 
these must not be used in the official tree. They can be used in 
overlays, or in case of rpm support just used to install rpm packages and 
achieve a bigger LSB support.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 16:54:58 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| What is then the purpose of paludis. Is its purpose to create a
| package manager for a new distro, and the paludis team would like to
| use gentoo as a testing ground?
| 
| Or is the purpose of the paludis team to have paludis be an
| alternative to portage. In that case it should respect portage, and
| make efforts to follow the standard that portage sets.

No single purpose. Approximate goals are usually as follows:

* The QA tool part, which has already found a whole load of issues in
the tree and has had them fixed.

* An alternative to Portage.

Paludis itself is distribution agnostic. It can be used on a Gentoo
system or on a non-Gentoo system as the user prefers.

Paludis does not attempt to emulate every last oddity of Portage. It
does not attempt to be usable in parallel with Portage, since that
would prevent any useful features from being added. It *does* attempt
to work with all existing ebuilds. It *can* read Portage-generated VDB,
although at this stage we're strongly encouraging people not to try
that, because there will probably be a few bugs...

| What I have done is stated:
| - Why paludis accomodations are too early at this moment

By the same argument, icc shouldn't be in the tree.

| - Why package managers should not have their own profiles

Yes, very nice in theory. Unfortunately, Portage requires a whole load
of Portage stuff in its profile, so that's not an option.

| - What categories of package managers can exist (candidate
| replacement, secondary, third-party)

This categorisation is a false trichotomy. There is no reason for it to
exist, and it has no value.

| - That there can only one primary package manager
| - What requirements exist for a secondary package manager
| - What requirements exist for a candidate replacement package manager

Again, nonsense based upon some random arbitrary segregation you're
attempting to make that has no real world relevance.

| One of the biggest issues for amd64 is the fact that packages can not
| be installed for particular architectures or in paralel. An
| alternative package manager could offer a way that while allowing
| each architecture to be installed separately, it merges the files
| into one package and maintains separate files that record which
| subpackage which file belongs to. This way portage can remove the
| package, see that it's there and even verify the contents. It only
| can not itself provide multi architecture installation.

Can't be done without huge ebuild changes. And were we to do that, we'd
just implement multi-abi properly. Which would be trivial with Paludis
and impossible with Portage.

| Another thing is reverse dependencies. This is missing from portage,
| but a feature that could well be implemented independent of the
| on-disk system.

Yes, carry on looking at the small picture. It's really really
interesting!

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Wernfried Haas]

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

On Thu, May 18, 2006 at 06:11:35PM +0100, Ciaran McCreesh wrote:
> Again, nonsense based upon some random arbitrary segregation you're
> attempting to make that has no real world relevance.

> Yes, carry on looking at the small picture. It's really really
> interesting!

Please refrain from making such (and similar) comments on the
gentoo-dev list. 

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: 191 bytes --]

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 19:14:16 +0200 Wernfried Haas <amne@gentoo.org>
wrote:
| On Thu, May 18, 2006 at 06:11:35PM +0100, Ciaran McCreesh wrote:
| > Again, nonsense based upon some random arbitrary segregation you're
| > attempting to make that has no real world relevance.
| 
| > Yes, carry on looking at the small picture. It's really really
| > interesting!
| 
| Please refrain from making such (and similar) comments on the
| gentoo-dev list. 

What, pointing out that the entire argument is bogus? It's kinda like
this:

Bash is Gentoo's primary shell. ZSH cannot be included in the tree as
the primary shell unless it can work with every bash shell script
(including ebuilds) without any changes (including paths and
environment variables) to anything. ZSH cannot be included in the tree
as a secondary shell if it can be used to do anything that Bash can do,
including generating the .bash_history file. ZSH cannot be included in
the tree if it has any features that Bash does not.

However, you are allowed to use ZSH to display a picture of an ASCII
cow, because Bash doesn't do that at the moment.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Carsten Lohrke]

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

On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote:
>It's kinda like this:

Stop making such odd and wrong comparisons. The package manager is part of 
what defines a distribution, choosing a shell is the users choice. If you 
want to make the package manager matter of choice, start your own 
distribution.


Carsten

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 20:20:29 +0200 Carsten Lohrke <carlo@gentoo.org>
wrote:
| On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote:
| >It's kinda like this:
| 
| Stop making such odd and wrong comparisons. The package manager is
| part of what defines a distribution, choosing a shell is the users
| choice. If you want to make the package manager matter of choice,
| start your own distribution.

How many package managers does Debian have? What about Fedora?

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Thu, May 18, 2006 at 07:34:16PM +0100, Ciaran McCreesh wrote:
> On Thu, 18 May 2006 20:20:29 +0200 Carsten Lohrke <carlo@gentoo.org>
> wrote:
> | On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote:
> | >It's kinda like this:
> | 
> | Stop making such odd and wrong comparisons. The package manager is
> | part of what defines a distribution, choosing a shell is the users
> | choice. If you want to make the package manager matter of choice,
> | start your own distribution.
> 
> How many package managers does Debian have? What about Fedora?

They all support the exact same format.

You're changing the format, dropping what you dislike- they also 
support the same installed pkgs backend last I looked, again, not the 
case for paludis.

Better example please, because they're doing what paludis *should* be 
doing.

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 11:51:16 -0700 Brian Harring <ferringb@gmail.com>
wrote:
| On Thu, May 18, 2006 at 07:34:16PM +0100, Ciaran McCreesh wrote:
| > On Thu, 18 May 2006 20:20:29 +0200 Carsten Lohrke <carlo@gentoo.org>
| > wrote:
| > | On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote:
| > | >It's kinda like this:
| > | 
| > | Stop making such odd and wrong comparisons. The package manager is
| > | part of what defines a distribution, choosing a shell is the users
| > | choice. If you want to make the package manager matter of choice,
| > | start your own distribution.
| > 
| > How many package managers does Debian have? What about Fedora?
| 
| They all support the exact same format.
| 
| You're changing the format, dropping what you dislike- they also 
| support the same installed pkgs backend last I looked, again, not the 
| case for paludis.

No, they have a common subset of shared operations, just as Paludis and
Portage do.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Thu, May 18, 2006 at 08:04:36PM +0100, Ciaran McCreesh wrote:
> On Thu, 18 May 2006 11:51:16 -0700 Brian Harring <ferringb@gmail.com>
> wrote:
> | On Thu, May 18, 2006 at 07:34:16PM +0100, Ciaran McCreesh wrote:
> | > On Thu, 18 May 2006 20:20:29 +0200 Carsten Lohrke <carlo@gentoo.org>
> | > wrote:
> | > | On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote:
> | > | >It's kinda like this:
> | > | 
> | > | Stop making such odd and wrong comparisons. The package manager is
> | > | part of what defines a distribution, choosing a shell is the users
> | > | choice. If you want to make the package manager matter of choice,
> | > | start your own distribution.
> | > 
> | > How many package managers does Debian have? What about Fedora?
> | 
> | They all support the exact same format.
> | 
> | You're changing the format, dropping what you dislike- they also 
> | support the same installed pkgs backend last I looked, again, not the 
> | case for paludis.
> 
> No, they have a common subset of shared operations, just as Paludis and
> Portage do.

They have a common subset of shared *high level* operations, 
resolution differing dependant on the high level component used.

Note I said 'high level', not low level, ie the format (which is what 
my point was).

This is why despite most distro level bastardizations of the rpm spec,
things still work- they're relying on a common tool/lib to handle low 
level details, rather then reimplementing them (and changing them) as 
paludis does.

Simply put, others have a seperation between high level functionality 
(resolution, fetching, etc), and the low level format- high level 
differs elsewhere (leading to some fun issues like apt-rpm's inability 
to install N versions of a pkg), but the format bits are still common 
to that distro (rather then reimplemented by each).

So no... not a valid counterarg- paludis relationship to portage 
(namely, we're going to do what we think is best format level despite 
what portage does) directly contradicts your arguement.

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Roy Marples]

On Thursday 18 May 2006 19:20, Carsten Lohrke wrote:
> On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote:
> >It's kinda like this:
>
> Stop making such odd and wrong comparisons. The package manager is part of
> what defines a distribution, choosing a shell is the users choice. If you
> want to make the package manager matter of choice, start your own
> distribution.

Yes, part of it. baselayout is another part - and yet it's possible to run 
Gentoo on other variants like initng, daemontools and no doubt others. I 
believe that embedded doesn't use baselayout as such because we rely on bash 
and they rely on busybox. But last time I checked it was still Gentoo.

Or are you saying that SUSE is RedHat as they use RPM?

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo/Linux Developer (baselayout, networking)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Carsten Lohrke]

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

On Thursday 18 May 2006 20:43, Roy Marples wrote:
> Yes, part of it. baselayout is another part - and yet it's possible to run
> Gentoo on other variants like initng, daemontools and no doubt others.

Sure baselayout is. An there're others in the tree, But that doesn't mean 
these variants are supported (special cases like embedded aside).

> Or are you saying that SUSE is RedHat as they use RPM?

Can you install SUSE and RedHat packages arbitrary mixed!? No, you can't 
(well, you can, but...).


Carsten

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 21:35:01 +0200 Carsten Lohrke <carlo@gentoo.org>
wrote:
| On Thursday 18 May 2006 20:43, Roy Marples wrote:
| > Yes, part of it. baselayout is another part - and yet it's possible
| > to run Gentoo on other variants like initng, daemontools and no
| > doubt others.
| 
| Sure baselayout is. An there're others in the tree, But that doesn't
| mean these variants are supported (special cases like embedded aside).

Sure, some of them are supported.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Carsten Lohrke]

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

On Thursday 18 May 2006 22:15, Ciaran McCreesh wrote:
> | Sure baselayout is. An there're others in the tree, But that doesn't
> | mean these variants are supported (special cases like embedded aside).
>
> Sure, some of them are supported.

By supported I mean all relevant packages in the tree install matching init 
scripts. That means officially supported, compared to such a package being 
maintained.


Carsten

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

Re: [gentoo-dev] Paludis and Profiles

[Roy Marples]

On Friday 19 May 2006 14:54, Carsten Lohrke wrote:
> On Thursday 18 May 2006 22:15, Ciaran McCreesh wrote:
> > | Sure baselayout is. An there're others in the tree, But that doesn't
> > | mean these variants are supported (special cases like embedded aside).
> >
> > Sure, some of them are supported.
>
> By supported I mean all relevant packages in the tree install matching init
> scripts. That means officially supported, compared to such a package being
> maintained.

I can show you bugs where existing packages have invalid init scripts that 
just don't work with any baselayout version in portage. You could argue that 
they shouldn't be in the tree - if so then our imap server is foo-bared as it 
uses courier-imap. I suggest you check out bug #98745 for a clear definition 
of "support".

I can also show you Gentoo scripts used by ifplugd and netplug with init-ng 
support in the tree right now. I guess that means that init-ng has some level 
of support right?

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo/Linux Developer (baselayout, networking)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Carsten Lohrke]

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

On Friday 19 May 2006 16:17, Roy Marples wrote:
> I can show you bugs where existing packages have invalid init scripts that
> just don't work with any baselayout version in portage. You could argue 
> that they shouldn't be in the tree - if so then our imap server is
> foo-bared as it uses courier-imap. I suggest you check out bug #98745 for a
> clear definition of "support".

Bugs exist and should be fixed, but this is by no means an argument.

> I can also show you Gentoo scripts used by ifplugd and netplug with init-ng
> support in the tree right now. I guess that means that init-ng has some
> level of support right?

There will be always someone who goes ahead. Fact is that every dev who 
maintains a package installing an init script is expecteted to do so for 
baselayout, but is free to say no, when someone requests an initng one, as 
long as it isn't the Gentoo default.


Carsten

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

Re: [gentoo-dev] Paludis and Profiles

[Roy Marples]

On Friday 19 May 2006 15:52, Carsten Lohrke wrote:
> There will be always someone who goes ahead. Fact is that every dev who
> maintains a package installing an init script is expecteted to do so for
> baselayout, but is free to say no, when someone requests an initng one, as
> long as it isn't the Gentoo default.

You heard it guys - rip the djb stuff out of portage until the devs write 
scripts for baselayout. They have scripts for daemontools, but apparently 
it's not the Gentoo default.

Or should we make an exception like you did for embedded?

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo/Linux Developer (baselayout, networking)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Thu, 18 May 2006 21:35:01 +0200
Carsten Lohrke <carlo@gentoo.org> wrote:

> Sure baselayout is. An there're others in the tree, But that doesn't
> mean these variants are supported (special cases like embedded aside).

So they're unsupported alternatives to one of the core parts of gentoo,
which have profiles for them in the tree. What's different?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 22:37, Stephen Bennett wrote:
> On Thu, 18 May 2006 21:35:01 +0200
>
> Carsten Lohrke <carlo@gentoo.org> wrote:
> > Sure baselayout is. An there're others in the tree, But that doesn't
> > mean these variants are supported (special cases like embedded
> > aside).
>
> So they're unsupported alternatives to one of the core parts of gentoo,
> which have profiles for them in the tree. What's different?

They are at least partly supported. Also they do not aim to replace 
baselayout as the main gentoo basic setup.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Roy Marples]

On Friday 19 May 2006 08:25, Paul de Vrieze wrote:
> On Thursday 18 May 2006 22:37, Stephen Bennett wrote:
> > On Thu, 18 May 2006 21:35:01 +0200
> >
> > Carsten Lohrke <carlo@gentoo.org> wrote:
> > > Sure baselayout is. An there're others in the tree, But that doesn't
> > > mean these variants are supported (special cases like embedded
> > > aside).
> >
> > So they're unsupported alternatives to one of the core parts of gentoo,
> > which have profiles for them in the tree. What's different?
>
> They are at least partly supported. Also they do not aim to replace
> baselayout as the main gentoo basic setup.

As someone who's talked to initng devs since their project began and someone 
who has contribed code so that networking worked on init-ng with a Gentoo 
config I can assure you that their goal is to replace baselayout in Gentoo.

OMFG - lets rip initng from the tree as it's going to replace my lovely 
baselayout</sarcasm>


-- 
Roy Marples <uberlord@gentoo.org>
Gentoo/Linux Developer (baselayout, networking)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Roy Marples]

On Thursday 18 May 2006 20:35, Carsten Lohrke wrote:
> On Thursday 18 May 2006 20:43, Roy Marples wrote:
> > Yes, part of it. baselayout is another part - and yet it's possible to
> > run Gentoo on other variants like initng, daemontools and no doubt
> > others.
>
> Sure baselayout is. An there're others in the tree, But that doesn't mean
> these variants are supported (special cases like embedded aside).

Why make a special case for embedded?
Maybe you haven't noticed, but baselayout is a virtual - which does make 
things harder as the main "forks" (vserver and fbsd) sometimes break when we 
add new things and they haven't synced up yet.

But that's OK as they're supported I guess.

Or are you saying that spb, other devs and people outside of Gentoo who has 
submitted SoC applications about Paludis (or what that qaludis?) are just 
going to wack it into the tree and then say "we're not going to support it"?

Of course not!

If az, vapier and myself upped and left Gentoo, would you rip out baselayout 
in favour of something else as there's no-one to support it?

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo/Linux Developer (baselayout, networking)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Carsten Lohrke]

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

On Friday 19 May 2006 09:33, Roy Marples wrote:
> Maybe you haven't noticed, but baselayout is a virtual - which does make
> things harder as the main "forks" (vserver and fbsd) sometimes break when
> we add new things and they haven't synced up yet.

I have nothing against a virtual. I just don't think polluting the profile 
subtree with alternative package mananger stuff is good idea.

> But that's OK as they're supported I guess.
>
> Or are you saying that spb, other devs and people outside of Gentoo who has
> submitted SoC applications about Paludis (or what that qaludis?) are just
> going to wack it into the tree and then say "we're not going to support
> it"?
>
> Of course not!

No, I'm saying it's not the Gentoo package manager. Work on it, make it a 
viable contender for replacing Portage, but as long it isn't, keep it in an 
overlay.


Carsten

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

Re: [gentoo-dev] Paludis and Profiles

[Grant Goodyear]

Carsten Lohrke wrote:
> Stop making such odd and wrong comparisons. The package manager is part of 
> what defines a distribution, choosing a shell is the users choice. If you 
> want to make the package manager matter of choice, start your own 
> distribution.

Just because it has historically been the case that a package manager
often defines a distribution, that hardly means that it must do so.
(Incidentally, I think that apt-with-rpm probably broke that perception
long ago.)

In any event, the ultimate issue, as far as I can tell, is whether or
not it makes sense to have a package manager that would need to be
chosen at the point of installation, but that would use the existing
tree of ebuilds just as portage does.  Would that be a Gentoo system?
Personally, I don't see why it wouldn't, as it doesn't seem that
different from deciding at install time to choose a BSD kernel and
userland.  Some modifications are required to use the system
successfully compared to a default Gentoo Linux installation, but the
overall philosophy remains the same.

Now, would it be vastly more convenient if one could switch between
portage and a portage alternative with no more hassle than running some
sort of "conversion" scripts?  Of course, and I suspect that somebody
would write such scripts even if the lead devs didn't do it themselves,
but I'm not sure that the bar for acceptance needs to be that high.

-g2boojum-

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote:
> On Thu, 18 May 2006 19:14:16 +0200 Wernfried Haas <amne@gentoo.org>
>
> Bash is Gentoo's primary shell. ZSH cannot be included in the tree as
> the primary shell unless it can work with every bash shell script
> (including ebuilds) without any changes (including paths and
> environment variables) to anything. ZSH cannot be included in the tree
> as a secondary shell if it can be used to do anything that Bash can do,
> including generating the .bash_history file. ZSH cannot be included in
> the tree if it has any features that Bash does not.

You can't seriously mean that. I'm not even going to try to point out that 
this is a rediculous analogy as you will not get the point anyway.

Also paludis can be accepted in three if it does things that portage does not 
do. Ebuilds in the tree that are not specific to paludis must continue to 
function with portage. Otherwise the official package manager would not be 
able to use the official tree.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 18:11, Ciaran McCreesh wrote:
> On Thu, 18 May 2006 16:54:58 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | What is then the purpose of paludis. Is its purpose to create a
> | package manager for a new distro, and the paludis team would like to
> | use gentoo as a testing ground?
> |
> | Or is the purpose of the paludis team to have paludis be an
> | alternative to portage. In that case it should respect portage, and
> | make efforts to follow the standard that portage sets.
>
> No single purpose. Approximate goals are usually as follows:
>
> * The QA tool part, which has already found a whole load of issues in
> the tree and has had them fixed.

No problem with that.

> * An alternative to Portage.
>
> Paludis itself is distribution agnostic. It can be used on a Gentoo
> system or on a non-Gentoo system as the user prefers.

This would make it a third party packaging solution that happens to work to 
some extend with ebuilds. This would give paludis the big flexibility, not 
supported by gentoo option. This means that no paludis specific changes must 
be made to the tree.
>
> Paludis does not attempt to emulate every last oddity of Portage. It
> does not attempt to be usable in parallel with Portage, since that
> would prevent any useful features from being added. It *does* attempt
> to work with all existing ebuilds. It *can* read Portage-generated VDB,
> although at this stage we're strongly encouraging people not to try
> that, because there will probably be a few bugs...

That makes it not suitable to be used in replacement primary packager or 
secondary packager roles. Leaving the third party role. Gentoo support would 
thus send the wrong signal.

> | What I have done is stated:
> | - Why paludis accomodations are too early at this moment
>
> By the same argument, icc shouldn't be in the tree.

Even if that is true, icc has been in the tree since (12 Apr 2002) making it a 
historical mistake that should be avoided for the future.

>
> | - Why package managers should not have their own profiles
>
> Yes, very nice in theory. Unfortunately, Portage requires a whole load
> of Portage stuff in its profile, so that's not an option.

Then submit patches to portage to make it profile agnostic.

> | - What categories of package managers can exist (candidate
> | replacement, secondary, third-party)
>
> This categorisation is a false trichotomy. There is no reason for it to
> exist, and it has no value.

Why and why?

>
> | - That there can only one primary package manager
> | - What requirements exist for a secondary package manager
> | - What requirements exist for a candidate replacement package manager
>
> Again, nonsense based upon some random arbitrary segregation you're
> attempting to make that has no real world relevance.

Baseless accusations that are not supported by any argumentation. As long as 
you don't provide arguments I'll assume that you are out of arguments and try 
to convince me by baffling me.

>
> | One of the biggest issues for amd64 is the fact that packages can not
> | be installed for particular architectures or in paralel. An
> | alternative package manager could offer a way that while allowing
> | each architecture to be installed separately, it merges the files
> | into one package and maintains separate files that record which
> | subpackage which file belongs to. This way portage can remove the
> | package, see that it's there and even verify the contents. It only
> | can not itself provide multi architecture installation.
>
> Can't be done without huge ebuild changes. And were we to do that, we'd
> just implement multi-abi properly. Which would be trivial with Paludis
> and impossible with Portage.

I can easilly come up with a way to do it without portage changes. It causes 
some stuff to be compiled too often, but does not break things. I can even 
invent some way that it does not "conflict" with portage VDB's. Why don't you 
use your intelligence to find ways to do things that do not conflict with 
portage (or people).

>
> | Another thing is reverse dependencies. This is missing from portage,
> | but a feature that could well be implemented independent of the
> | on-disk system.
>
> Yes, carry on looking at the small picture. It's really really
> interesting!

These are just examples. Another example of a secondary package manager would 
be one that would allow installation of rpm packages in a portage compatible 
way. I'm not hurt by you calling me names. It just shows that the accusations 
against you were right.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 20:18:24 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| > * An alternative to Portage.
| >
| > Paludis itself is distribution agnostic. It can be used on a Gentoo
| > system or on a non-Gentoo system as the user prefers.
| 
| This would make it a third party packaging solution that happens to
| work to some extend with ebuilds.

No, it works with a large part of the tree without modification. I'm
not going to say all, because there're no doubt ebuilds out there that
won't work (just as there are some that won't work with Portage), but
Paludis is quite happy installing system + X + KDE + Gnome + all the
stuff I use.

| This would give paludis the big
| flexibility, not supported by gentoo option. This means that no
| paludis specific changes must be made to the tree.

Why? Changes are made to the tree to support other packages all the
time.

| > Paludis does not attempt to emulate every last oddity of Portage. It
| > does not attempt to be usable in parallel with Portage, since that
| > would prevent any useful features from being added. It *does*
| > attempt to work with all existing ebuilds. It *can* read
| > Portage-generated VDB, although at this stage we're strongly
| > encouraging people not to try that, because there will probably be
| > a few bugs...
| 
| That makes it not suitable to be used in replacement primary packager
| or secondary packager roles. Leaving the third party role. Gentoo
| support would thus send the wrong signal.

Again, you're falling back on meaningless categorisations. There is no
such thing as a primary or secondary package manager.

| > | What I have done is stated:
| > | - Why paludis accomodations are too early at this moment
| >
| > By the same argument, icc shouldn't be in the tree.
| 
| Even if that is true, icc has been in the tree since (12 Apr 2002)
| making it a historical mistake that should be avoided for the future.

And ZSH?

| > | - Why package managers should not have their own profiles
| >
| > Yes, very nice in theory. Unfortunately, Portage requires a whole
| > load of Portage stuff in its profile, so that's not an option.
| 
| Then submit patches to portage to make it profile agnostic.

I'm sorry, but waiting three years isn't exactly ideal here...

| > | - What categories of package managers can exist (candidate
| > | replacement, secondary, third-party)
| >
| > This categorisation is a false trichotomy. There is no reason for
| > it to exist, and it has no value.
| 
| Why and why?

Ok, in simpler language: You are pulling this whole "primary /
secondary" thing out of your ass. It has no more meaning than "Package
managers that have the letter 'o' in their name" / "Package managers
that do not have the letter 'o' in their name".

| > | - That there can only one primary package manager
| > | - What requirements exist for a secondary package manager
| > | - What requirements exist for a candidate replacement package
| > | manager
| >
| > Again, nonsense based upon some random arbitrary segregation you're
| > attempting to make that has no real world relevance.
| 
| Baseless accusations that are not supported by any argumentation. As
| long as you don't provide arguments I'll assume that you are out of
| arguments and try to convince me by baffling me.

*You* are the one making baseless claims. There is no such thing as a
"primary package manager" that is in any way more meaningful than "a
package manager that has the letter 'o' in its name".

| I can easilly come up with a way to do it without portage changes. It
| causes some stuff to be compiled too often, but does not break
| things. I can even invent some way that it does not "conflict" with
| portage VDB's. Why don't you use your intelligence to find ways to do
| things that do not conflict with portage (or people).

You can't come up with a reasonable, usable solution that doesn't
require ebuild changes. Nor can you come up with a solution to the VDB
issue that is not an ugly hack -- you don't even know what the
requirements are.

| > | Another thing is reverse dependencies. This is missing from
| > | portage, but a feature that could well be implemented independent
| > | of the on-disk system.
| >
| > Yes, carry on looking at the small picture. It's really really
| > interesting!
| 
| These are just examples. Another example of a secondary package
| manager would be one that would allow installation of rpm packages in
| a portage compatible way. I'm not hurt by you calling me names. It
| just shows that the accusations against you were right.

Again, you're falling back on this whole "secondary package manager"
thing. It has no meaning!

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Thu, May 18, 2006 at 07:33:27PM +0100, Ciaran McCreesh wrote:
> On Thu, 18 May 2006 20:18:24 +0200 Paul de Vrieze <pauldv@gentoo.org>
> wrote:
> | > * An alternative to Portage.
> | >
> | > Paludis itself is distribution agnostic. It can be used on a Gentoo
> | > system or on a non-Gentoo system as the user prefers.
> | 
> | This would make it a third party packaging solution that happens to
> | work to some extend with ebuilds.
> 
> No, it works with a large part of the tree without modification. I'm
> not going to say all, because there're no doubt ebuilds out there that
> won't work (just as there are some that won't work with Portage), but
> Paludis is quite happy installing system + X + KDE + Gnome + all the
> stuff I use.
> 
> | This would give paludis the big
> | flexibility, not supported by gentoo option. This means that no
> | paludis specific changes must be made to the tree.
> 
> Why? Changes are made to the tree to support other packages all the
> time.
> 
> | > Paludis does not attempt to emulate every last oddity of Portage. It
> | > does not attempt to be usable in parallel with Portage, since that
> | > would prevent any useful features from being added. It *does*
> | > attempt to work with all existing ebuilds. It *can* read
> | > Portage-generated VDB, although at this stage we're strongly
> | > encouraging people not to try that, because there will probably be
> | > a few bugs...
> | 
> | That makes it not suitable to be used in replacement primary packager
> | or secondary packager roles. Leaving the third party role. Gentoo
> | support would thus send the wrong signal.
> 
> Again, you're falling back on meaningless categorisations. There is no
> such thing as a primary or secondary package manager.

<snip>

> Ok, in simpler language: You are pulling this whole "primary /
> secondary" thing out of your ass. It has no more meaning than "Package
> managers that have the letter 'o' in their name" / "Package managers
> that do not have the letter 'o' in their name".

<snip>

> *You* are the one making baseless claims. There is no such thing as a
> "primary package manager" that is in any way more meaningful than "a
> package manager that has the letter 'o' in its name".
> 

Please talk to the OSX folk- they would disagree, since 
collision-protect was added to keep gentoo-osx from stomping on the 
primary installation (iow, to keep the secondary from acting like it 
was primary).  Since you also spent a lot of time 'contributing' to 
prefix, I'd expect you'd understand the primary vs secondary role also 
(same with since you've ranted at autopackage).

What he is driving it at is that either paludis is an alternative (yet 
on disk compatible) primary, or it's a secondary- you keep debating 
the compatibility angle, thus the logical conclussion is that it's a 
secondary.


> | I can easilly come up with a way to do it without portage changes. It
> | causes some stuff to be compiled too often, but does not break
> | things. I can even invent some way that it does not "conflict" with
> | portage VDB's. Why don't you use your intelligence to find ways to do
> | things that do not conflict with portage (or people).
> 
> You can't come up with a reasonable, usable solution that doesn't
> require ebuild changes. Nor can you come up with a solution to the VDB
> issue that is not an ugly hack -- you don't even know what the
> requirements are.

Re: vdb, the virtuals hack you've slipped in is paludis choice- you 
design your manager properly, the vdb backend can be swapped out.  In 
other words, collect virtuals on the fly (ala portage/preexisting vdb 
compatible), or convert that backend to a format that has the virtuals 
flattened.

Bluntly, if I can do it in pkgcore, you ought to be able to do it in 
paludis.  It's just a matter of designing your repositories properly, 
you went for on disk virtuals to be faster at the cost of 
compatibility.  Same for copying eclasses in, instead of doing env 
reinstating (you already keep a copy of the env), you went for "well, 
we'll fix it by copying the eclass in"- went for the quick route 
rather then the proper solution (again, if I can do it sanely in 
pkgcore, no reason you can't).

Without clarifying the actual contents level difference (beyond 
collapsing fif/dev into misc), aka the "we can't convert because of 
symlink/dir issues", hard to comment on it- without an example, 
inclined to think it's not a vdb backend difference, just an unmerge 
strategy difference.

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 12:41:47 -0700 Brian Harring <ferringb@gmail.com>
wrote:
| Please talk to the OSX folk- they would disagree, since 
| collision-protect was added to keep gentoo-osx from stomping on the 
| primary installation (iow, to keep the secondary from acting like it 
| was primary).  Since you also spent a lot of time 'contributing' to 
| prefix, I'd expect you'd understand the primary vs secondary role
| also (same with since you've ranted at autopackage).

Except that by that definition, Paludis *is* a primary package manager.

| What he is driving it at is that either paludis is an alternative
| (yet on disk compatible) primary, or it's a secondary- you keep
| debating the compatibility angle, thus the logical conclussion is
| that it's a secondary.

We're an alternative, not entirely on disc compatible primary.

| Re: vdb, the virtuals hack you've slipped in is paludis choice- you 
| design your manager properly, the vdb backend can be swapped out.  In 
| other words, collect virtuals on the fly (ala portage/preexisting vdb 
| compatible), or convert that backend to a format that has the
| virtuals flattened.
| 
| Bluntly, if I can do it in pkgcore, you ought to be able to do it in 
| paludis. 

Design choice. We chose not to continue with previous design mistakes
that exist only because of limitations in Portage's dep resolver where
we can do so without requiring ebuild changes.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 22:19, Ciaran McCreesh wrote:
> On Thu, 18 May 2006 12:41:47 -0700 Brian Harring <ferringb@gmail.com>
>
> wrote:
> | Please talk to the OSX folk- they would disagree, since
> | collision-protect was added to keep gentoo-osx from stomping on the
> | primary installation (iow, to keep the secondary from acting like it
> | was primary).  Since you also spent a lot of time 'contributing' to
> | prefix, I'd expect you'd understand the primary vs secondary role
> | also (same with since you've ranted at autopackage).
>
> Except that by that definition, Paludis *is* a primary package manager.

It is capable of being a primary package manager. On gentoo it is not the 
primary package manager as that requires a council decision. Such a decision 
would amount to deprecating portage.

>
> | What he is driving it at is that either paludis is an alternative
> | (yet on disk compatible) primary, or it's a secondary- you keep
> | debating the compatibility angle, thus the logical conclussion is
> | that it's a secondary.
>
> We're an alternative, not entirely on disc compatible primary.

This means that you could choose to meet the requirements that I am currently 
writing down in GLEP shape for package managers that desire to replace 
portage as the primary package manager. Those requirements can be met, but 
would limit the freedom choise of implementation of the package manager.

> Design choice. We chose not to continue with previous design mistakes
> that exist only because of limitations in Portage's dep resolver where
> we can do so without requiring ebuild changes.

This is a valid design choise. It does however mean that paludis perhaps can 
not meet the requirements for being a replacement for portage as gentoo 
primary package manager.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 22:39:20 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| > Except that by that definition, Paludis *is* a primary package
| > manager.
| 
| It is capable of being a primary package manager. On gentoo it is not
| the primary package manager as that requires a council decision. Such
| a decision would amount to deprecating portage.

No, it's a choice best left up to the users. Ignoring Paludis and
pretending it doesn't exist won't make it go away.

| > | What he is driving it at is that either paludis is an alternative
| > | (yet on disk compatible) primary, or it's a secondary- you keep
| > | debating the compatibility angle, thus the logical conclussion is
| > | that it's a secondary.
| >
| > We're an alternative, not entirely on disc compatible primary.
| 
| This means that you could choose to meet the requirements that I am
| currently writing down in GLEP shape for package managers that desire
| to replace portage as the primary package manager. Those requirements
| can be met, but would limit the freedom choise of implementation of
| the package manager.

GLEPs are to *Enhance*, not to hold back.

| > Design choice. We chose not to continue with previous design
| > mistakes that exist only because of limitations in Portage's dep
| > resolver where we can do so without requiring ebuild changes.
| 
| This is a valid design choise. It does however mean that paludis
| perhaps can not meet the requirements for being a replacement for
| portage as gentoo primary package manager.

You could come up with a requirement saying that "any replacement for
Portage must have an 'o' in its name". Wouldn't make it a valid
requirement. Fact is, Paludis can be used as and is being used as a
primary package manager.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Thu, May 18, 2006 at 09:58:02PM +0100, Ciaran McCreesh wrote:
> On Thu, 18 May 2006 22:39:20 +0200 Paul de Vrieze <pauldv@gentoo.org>
> | > | What he is driving it at is that either paludis is an alternative
> | > | (yet on disk compatible) primary, or it's a secondary- you keep
> | > | debating the compatibility angle, thus the logical conclussion is
> | > | that it's a secondary.
> | >
> | > We're an alternative, not entirely on disc compatible primary.
> | 
> | This means that you could choose to meet the requirements that I am
> | currently writing down in GLEP shape for package managers that desire
> | to replace portage as the primary package manager. Those requirements
> | can be met, but would limit the freedom choise of implementation of
> | the package manager.
> 
> GLEPs are to *Enhance*, not to hold back.

Several of your gleps restrict the tree (rhetoric not withstanding)- 
this is fundamentally no different, it's a restriction on what the is 
required of a pkg manager for it to be a primary available in the 
tree- this includes whatever profiles/mods it requires/wants.


> | > Design choice. We chose not to continue with previous design
> | > mistakes that exist only because of limitations in Portage's dep
> | > resolver where we can do so without requiring ebuild changes.
> | 
> | This is a valid design choise. It does however mean that paludis
> | perhaps can not meet the requirements for being a replacement for
> | portage as gentoo primary package manager.
> 
> You could come up with a requirement saying that "any replacement for
> Portage must have an 'o' in its name". Wouldn't make it a valid
> requirement. Fact is, Paludis can be used as and is being used as a
> primary package manager.

No one is disputing that.  What they are disputing is whether paludis 
has any place in the tree if it's not going to be ondisk (whether 
profile, ebuild, or vdb) compatible with portage.

Say paludis *did* get into the tree, and the changes you've coded into 
paludis already took hold- we would have a tree that is part paludis, 
and part portage.

If it's not going to be compatible under guidelines council/approved 
glep dictates, then it has no place in the tree.

Aside from that, lay off the smart ass "any replacement for portage 
must have an 'o' in its name" crap- folks aren't going to budge on 
this one, so just address the points they're raising rather then 
dodging it (thus requiring another email from 'em dragging the answer 
out of you).

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 22:19:16 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| On Thursday 18 May 2006 20:33, Ciaran McCreesh wrote:
| > *You* are the one making baseless claims. There is no such thing as
| > a "primary package manager" that is in any way more meaningful than
| > "a package manager that has the letter 'o' in its name".
| 
| +1 troll

And that's your argument? If you're just going to sink to accusing
anyone who disagrees with you of trolling then please retire gracefully
before you make an even bigger fool of yourself. I was hoping you could
continue providing constructive input as you were earlier on in the
thread, although it looks like you've nothing useful left to say and are
resorting to petty flaming.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 22:24, Ciaran McCreesh wrote:
> |
> | +1 troll
>
> And that's your argument? If you're just going to sink to accusing
> anyone who disagrees with you of trolling then please retire gracefully
> before you make an even bigger fool of yourself. I was hoping you could
> continue providing constructive input as you were earlier on in the
> thread, although it looks like you've nothing useful left to say and are
> resorting to petty flaming.

This was a private mail, that by choise of Ciaran was posted to this list.

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Alec Warner]

I've read every mail thus far (even the mails sent from next month <g>).

There is no technical reason that the profile shouldn't go in.  Past 
precedent is set, most of the kinks regarding the profile have been 
worked out, yet members of the community are dead set against the idea.

I think I was dead set against it too, a few weeks ago.

However, everyone has the silliest of reasons, or so it seems.  Everyone 
is afraid of switching, fear is good, fear keeps one cautious.  However 
fear is also stifling, stifling innovation in this instance.  Paludis is 
  a way forward, as is any portage rewrite.  It has bugs yes, it works 
for the most part yes.  So why not give it a fair shot?

Fear the Slipperly slope:
First a new profile, then an eclass, then the tree!  Paludis will take 
control of everything!

Only if you let it.  And to an extent, why not let it.  Who has to 
commit all that crap that uses all the new shiny features?  Thats right, 
developers do.  If thats the way developers wish to go, than thats the 
way Gentoo may go.  Of course, you need to keep standards in the tree, 
EAPI helps this a bit.  Use something new in Paludis, EAPI it.  Portage 
will gladly mask it properly.  This is where the problem lies however.

None of the paludis folk are asking for ebuild changes at this time.  I 
say give them their profile; tell them if they make any ebuild changes 
you will cut their nuts off.  Take it to the council and figure out a 
plan for migration, since there is more than one alternative coming up. 
  We may need a plan similar to the CVS migration where someone goes off 
and does some testing and figures out what is best for Gentoo.

The problem being with multiple implementations of something we have no 
standard for...they all need to match ;)  Otherwise paludis will end up 
being...well..a fork.

-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Mike Auty]

Perhaps,
	The problem here is that the paludis team appear to have a conflict of
interests due to their previous and/or current association with Gentoo.
 I know they've mentioned personal grudges, so despite not knowing who
these people are, I'm going to assume they have a history with Gentoo.
	However, were a new package manager (such as Conary) to request on the
Gentoo Developer list that the tree be changed to make their package
manager would work slightly better, I have no doubt that they would meet
a similarly mixed resistance.  Whilst there may not be an easily
explained technical reason not to make the change, there is no
compelling reason *to* make the change either.
	Most likely the response to this message will be that Paludis isn't the
same as Conary, and that it could eventually take over from portage.
However, other portage replacements (such as pkgcore and the seemingly
forgotten portage-C) have not required changes to the tree.
	No promises were made to the Paludis team concerning changes to the
tree (as far as I'm aware), and I don't see how any external package
management system could build their software *assuming* that they could
eventually influence a distribution's package library.  I am perfectly
happy for Paludis to innovate in whatever manner it deems necessary,
just as I am for Conary to develop, but (at the moment) as external
entities to Gentoo.
	Hopefully the council meeting will clear all of this up, and I look
forward to reading their decision...
	Mike  5:)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Christian Hartmann]

Ciaran McCreesh:
> And that's your argument? If you're just going to sink to accusing
> anyone who disagrees with you of trolling then please retire gracefully
> before you make an even bigger fool of yourself.

That's indeed funny.

/me wrote:
> That actually was a serious question. But you and your gang are good in
> avoiding answering questions that you are not comfortable with.

Now you are doing it again. - Even funnier that you cc'd devrel.

Ciaran McCreesh:
> I was hoping you could 
> continue providing constructive input as you were earlier on in the
> thread

That's what you are really after? I'm still waiting for you to answer my 
questions then.

-- 
Christian Hartmann
http://www.gentoo.org/~ian/

PGP Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865
Key fingerprint = 4544 EC0C BAE4 216F 5981  7F95 2154 E5EE 692A 4865

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Wed, May 17, 2006 at 05:32:38PM +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 11:23:19 +0200 Wernfried Haas <amne@gentoo.org>
> wrote:
> | We really should figure that stuff out before we start integrating an
> | externally written package manager we have no influence on whatsoever
> 
> How much influence does your typical Gentoo developer or user have over
> the development of Portage? Please consider long-standing feature
> requests such as :slot and [use] deps in your answer.

Can we *please* avoid the portage bashing for at least a few days?  

As we've discussed in the past, sane base design and you can do 
use/slot without too much trouble.  Folks *do* request things of 
portage, and it *does* get added- multilib came about via requests 
from lv (pretty quick turn around), axxo's need for env tricks to deal 
with /etc/profile issues* results in pre/post phase hooks being added, 
etc.

Portage devs work with a crap source trying to implement what folks 
want- the code does fight certain features.  That doesn't mean you can 
construe it as "portage devs don't listen" as you're implying.

Besides that, lay off 'em.  Lot of people want features out of 
portage, but nobody ever steps up- usually what comes of it is just 
someone flaming them, rather then providing a patch.
~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Marius Mauch]

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

On Tue, 16 May 2006 16:15:49 +0100
Stephen Bennett <spb@gentoo.org> wrote:

> If noone has any strong reasonable objections, I'd like to add a
> Paludis profile to the tree. This would use Paludis as the default
> provider for virtual/portage (which is a less than ideal name, but
> that is another discussion entirely), and provide ebuild devs with a
> place where they can try out some of our profile enhancements should
> they want to. It is worth noting on the last point that most of these
> are long-standing Portage feature requests, at least some of which are
> planned for inclusion in Portage at some point in the future. This
> would allow devs access to them earlier, as a sort of testbed.

Why should this be handled differently than Gentoo/ALT projects?

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 01:15, Danny van Dyk wrote:
>
> There are several reasons to handle it slightly different:
> a) Paludis is a new package manager, not a different kernel nor
> userland.
> b) We don't need additional packages that need to go into the tree and
> which aren't used by any other arch than bsd.
> c) We don't need to keyword any packages.
> d) Paludis _can_ use existing profiles. There is no problem with that,
> and we did this for quite some time already. Interesting part is the
> multiple inheritance of profiles and the different (in my eyes
> improved) handling of profile configuration.
>
> In my eyes, these warrant adding a toplevel profile directory.

Your argumentation is unfortunately incomplete. Paludis is a package 
manager whose development and profiles can be tested largely outside the 
tree. While having a profile package for paludis might be inconvenient, 
the functionality is not different.

The main point you fail to mention however is that paludis is as yet not 
complete. At some point in the stabilisation of paludis gentoo has to 
decide whether paludis will receive some level of official support. At 
that time tests involving in-tree profiles can be conducted.

There are however a number of requirements I want to state that paludis 
should meet before I consider it a stable portage replacement:
- Paludis must be able to handle a standard portage /var/db/pkg tree. This
  means that paludis can read it, and write it. Enabling mixing portage
  and paludis up to some degree.
- Paludis must work with all current ebuilds, and support all features of
  portage. This includes recognition of EAPI, and no renaming of the
  variables used.
- No part of the tree, except those that by nature are paludis specific,
  may require the usage of paludis instead of portage. This requirement
  can only be removed after a decision is made by the council to retire
  portage in favour of paludis.
- It would be greatly beneficial if paludis would create and use .tbz2
  packages, but this is not essential.

Below I'll outline some of the consequences.

- Paludis may enhance ebuilds by directing the build process into a more
  efficient behaviour. As long as the ebuild still functions properly on
  portage, this should not be an issue. Examples would be in-ebuild
  documentation of use variables, enhanced dependency handling.
- Paludis enhanced packages (except paludis related ebuilds) should only
  be accepted into the tree when it is seen as a stable package manager.
- Paludis may choose to handle different format package descriptions
  (.ebuild.2?). Those can not appear in the official tree though before
  paludis is recognised as primary package manager.
- Overlays can be used for various ways to extend paludis.
- The first requirement of reading /var/db/pkg can be interpreted twofold.
  Either paludis should support it natively (as one of the options), or it
  should be able to convert from and to the /var/db/pkg format.
- It is allowed for out-of-tree package descriptions to require a
  different installed package database format. Things like paralel
  installation of 32bit and 64bit packages require this. As yet the tree
  should not offer this though.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 12:04:33 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| - Paludis must be able to handle a standard portage /var/db/pkg tree.
| This means that paludis can read it, and write it. Enabling mixing
| portage and paludis up to some degree.

Paludis can read a Portage-generated VDB. Portage can't read a
Paludis-generated VDB, because Paludis has more features.

| - Paludis must work with all current ebuilds, 

Portage does not work with all current ebuilds.

| and support all features of portage. 

That's insane. Why should we support Portage-style 'candy' spinners?

| This includes recognition of EAPI

Funnily enough, unlike Portage, Paludis has full EAPI handling.

| and no renaming of the variables used.

Why should Paludis emulate Portage internals that no-one uses?

| - No part of the tree, except those that by nature are paludis
| specific, may require the usage of paludis instead of portage. This
| requirement can only be removed after a decision is made by the
| council to retire portage in favour of paludis.

Again, insane. EAPI allows ebuilds using things that developers have
been after for years (you know, slot and use deps) to be in the tree in
such a way that they appear masked to Portage. That's a large part of
the point of EAPI.

| - It would be greatly beneficial if paludis would create and use .tbz2
|   packages, but this is not essential.

Paludis will use its own binary format.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 15:57, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 12:04:33 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | - Paludis must be able to handle a standard portage /var/db/pkg tree.
> | This means that paludis can read it, and write it. Enabling mixing
> | portage and paludis up to some degree.
>
> Paludis can read a Portage-generated VDB. Portage can't read a
> Paludis-generated VDB, because Paludis has more features.
>
> | - Paludis must work with all current ebuilds,
>
> Portage does not work with all current ebuilds.
>
> | and support all features of portage.
>
> That's insane. Why should we support Portage-style 'candy' spinners?

Let me clarify my statement. I don't care about candy spinners. Paludis 
(or any other package manager that is to be integrated into gentoo) 
should basically be able to allow a level of mix and match. This means 
that at the initial import, it can be run on any package instead of 
portage, and the results still be usable for portage (possibly after a 
conversion stage).

This allows testing out the package manager.

> | This includes recognition of EAPI
>
> Funnily enough, unlike Portage, Paludis has full EAPI handling.

Great. And I agree that EAPI was not taken as far as it should within 
portage.

> | and no renaming of the variables used.
>
> Why should Paludis emulate Portage internals that no-one uses?

If they are internals I don't care. If they are part of the API exposed to 
ebuilds then these variables should still be provided. If variables are 
not part of the public API, but still used regularly I consider them 
still part of the API.

> | - No part of the tree, except those that by nature are paludis
> | specific, may require the usage of paludis instead of portage. This
> | requirement can only be removed after a decision is made by the
> | council to retire portage in favour of paludis.
>
> Again, insane. EAPI allows ebuilds using things that developers have
> been after for years (you know, slot and use deps) to be in the tree in
> such a way that they appear masked to Portage. That's a large part of
> the point of EAPI.

Let's make clear why I put this in. Basically I am of the opinion that 
until a decision is made to make (in this case) paludis the primary 
package manager, all official packages should work with portage. Package 
masked packages are not considered official.

If this restriction is not applied, it would create the situation that a 
decision is forced upon the council by (paludis) having features 
available that the official primary  package manager has not. Thus 
requiring the use of a secondary package manager for certain 
applications. This in fact makes that package manager primary.

> | - It would be greatly beneficial if paludis would create and use
> | .tbz2 packages, but this is not essential.
>
> Paludis will use its own binary format.

I assume there are valid reasons. I agree that the binary support can be 
improved.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 17:11:04 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| Let me clarify my statement. I don't care about candy spinners.
| Paludis (or any other package manager that is to be integrated into
| gentoo) should basically be able to allow a level of mix and match.
| This means that at the initial import, it can be run on any package
| instead of portage, and the results still be usable for portage
| (possibly after a conversion stage).
| 
| This allows testing out the package manager.

Not realistic. It means that any new package manager can't do anything
new. I'd also like to point out that you can't upgrade to a new Portage
version, install some things, downgrade to an older Portage version and
expect things to carry on working.

| > | and no renaming of the variables used.
| >
| > Why should Paludis emulate Portage internals that no-one uses?
| 
| If they are internals I don't care. If they are part of the API
| exposed to ebuilds then these variables should still be provided. If
| variables are not part of the public API, but still used regularly I
| consider them still part of the API.

This, funnily enough, is what we're doing. We're supporting things that
are actually used, and things that people might reasonably use.

| > | - No part of the tree, except those that by nature are paludis
| > | specific, may require the usage of paludis instead of portage.
| > | This requirement can only be removed after a decision is made by
| > | the council to retire portage in favour of paludis.
| >
| > Again, insane. EAPI allows ebuilds using things that developers have
| > been after for years (you know, slot and use deps) to be in the
| > tree in such a way that they appear masked to Portage. That's a
| > large part of the point of EAPI.
| 
| Let's make clear why I put this in. Basically I am of the opinion
| that until a decision is made to make (in this case) paludis the
| primary package manager, all official packages should work with
| portage. Package masked packages are not considered official.

What of EAPI masked packages?

The same situation will occur when newer Portage versions supporting
newer EAPIs are released into p.mask or ~arch. Some packages will end
up relying upon something that isn't the stable package manager.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 17:26, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 17:11:04 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | Let me clarify my statement. I don't care about candy spinners.
> | Paludis (or any other package manager that is to be integrated into
> | gentoo) should basically be able to allow a level of mix and match.
> | This means that at the initial import, it can be run on any package
> | instead of portage, and the results still be usable for portage
> | (possibly after a conversion stage).
> |
> | This allows testing out the package manager.
>
> Not realistic. It means that any new package manager can't do anything
> new. I'd also like to point out that you can't upgrade to a new Portage
> version, install some things, downgrade to an older Portage version and
> expect things to carry on working.

No, a package manager can have many features. However, until it is seen as 
a candidate for becomming the primary package manager (or when it can 
function fully as secondary package manager (not being the boss in the 
installation tree)), the official tree may not rely on those features. 
Otherwise we get to a situation where the official tree relies on an 
unofficial package manager.

The difference between portage and paludis is that portage is the 
officially supported package manager. This support is limited to the 
newest versions, but it is still official. Until the decision is made to 
make paludis the official package manager it isn't. An unofficial package 
manager should not limit the usage of the official package manager.

> | If they are internals I don't care. If they are part of the API
> | exposed to ebuilds then these variables should still be provided. If
> | variables are not part of the public API, but still used regularly I
> | consider them still part of the API.
>
> This, funnily enough, is what we're doing. We're supporting things that
> are actually used, and things that people might reasonably use.

That is fair enough.

> | Let's make clear why I put this in. Basically I am of the opinion
> | that until a decision is made to make (in this case) paludis the
> | primary package manager, all official packages should work with
> | portage. Package masked packages are not considered official.
>
> What of EAPI masked packages?

Nah. If a package requires the use of a non-primary package manager, that 
package effectively forces the use of that package manager. If that 
non-primary package manager can not coexist with the official package 
manager, the package effectively blocks the usage of the primary package 
manager. By blocking the usage of the official package manager, the 
package becomes unofficial and has no place in the official tree.

This is basically to protect the official package manager. This is not 
because I like portage that much, but to provide some kind of unified 
direction. I am afraid that allowing various competing package managers 
would cause a wildfire of incompatible elements in the tree. Therefore 
there must be one official package manager that the tree works with.

> The same situation will occur when newer Portage versions supporting
> newer EAPIs are released into p.mask or ~arch. Some packages will end
> up relying upon something that isn't the stable package manager.

Portage is however the official package manager. This means that these 
packages do not hamper the position of the official package manager.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 17:48:32 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| This is basically to protect the official package manager. This is
| not because I like portage that much, but to provide some kind of
| unified direction. I am afraid that allowing various competing
| package managers would cause a wildfire of incompatible elements in
| the tree. Therefore there must be one official package manager that
| the tree works with.

You're saying "we must never move forward" here. There is no
requirement that users use packages that are EAPI masked, any more than
there is a requirement that users use packages that are package masked.
We have had situations in the past where some ebuilds have relied upon a
non-stable or hard-masked Portage version.

| > The same situation will occur when newer Portage versions supporting
| > newer EAPIs are released into p.mask or ~arch. Some packages will
| > end up relying upon something that isn't the stable package manager.
| 
| Portage is however the official package manager. This means that
| these packages do not hamper the position of the official package
| manager.

The "official package manager" isn't something that's in package.mask.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 18:05, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 17:48:32 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | This is basically to protect the official package manager. This is
> | not because I like portage that much, but to provide some kind of
> | unified direction. I am afraid that allowing various competing
> | package managers would cause a wildfire of incompatible elements in
> | the tree. Therefore there must be one official package manager that
> | the tree works with.
>
> You're saying "we must never move forward" here. There is no
> requirement that users use packages that are EAPI masked, any more than
> there is a requirement that users use packages that are package masked.
> We have had situations in the past where some ebuilds have relied upon a
> non-stable or hard-masked Portage version.

Currently we do not have any separation between core and non-core packages, 
but what would you say about this being the case for expat, and what about 
glibc? Every package that is not available to the official package manager 
hampers its credibility as the official package manager. In the case of a 
non-stable or hard-masked portage, this fact by itself limits the application 
of such packages. In case of an alternative package manager it is a lot 
easier to say "just install pkgcore (other contentor, to not mention paludis 
all the time), and it works". At that point this package manager takes over 
the role of primary package manager by the back door.

What I say is that we can move forward, but in conscious steps. There are many 
things that can be done without introducing packages to the tree that do not 
work with a current or planned version of the official package manager.

Please know that I don't mind portage being replaced. I don't think any of its 
developers are particularly in love with its spaghetti code. I do however 
think that a conscious decision should be made on whether and which package 
manager replaces portage.

> | > The same situation will occur when newer Portage versions supporting
> | > newer EAPIs are released into p.mask or ~arch. Some packages will
> | > end up relying upon something that isn't the stable package manager.
> |
> | Portage is however the official package manager. This means that
> | these packages do not hamper the position of the official package
> | manager.
>
> The "official package manager" isn't something that's in package.mask.

It is however certain that portage will be replaced at some point by a new 
portage that is either the package masked version, or that the package masked 
version is obsoleted.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.ru.nl
Homepage: http://www.devrieze.net

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Christian Hartmann]

> Not realistic. It means that any new package manager can't do anything
> new. I'd also like to point out that you can't upgrade to a new Portage
> version, install some things, downgrade to an older Portage version and
> expect things to carry on working.

This, funnily enough, is what people consider being a fork.

While you are at it, why don't you just fork the portage tree? By doing so you 
would have the freedom to do whatever you want to do without keeping gentoo 
busy reading your mails.

-- 
Christian Hartmann
http://www.gentoo.org/~ian/

PGP Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865
Key fingerprint = 4544 EC0C BAE4 216F 5981  7F95 2154 E5EE 692A 4865

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 17:54:36 +0200 Christian Hartmann <ian@gentoo.org>
wrote:
| > Not realistic. It means that any new package manager can't do
| > anything new. I'd also like to point out that you can't upgrade to
| > a new Portage version, install some things, downgrade to an older
| > Portage version and expect things to carry on working.
| 
| This, funnily enough, is what people consider being a fork.
| 
| While you are at it, why don't you just fork the portage tree? By
| doing so you would have the freedom to do whatever you want to do
| without keeping gentoo busy reading your mails.

On Tue, 16 May 2006 13:38:33 -0400 Mike Frysinger <vapier@gentoo.org>
wrote:
| if you dont have anything constructive to contribute then dont bother
| writing an e-mail

Know why this thread's so big? People like you posting crap to it and
interfering with what would otherwise be a technical discussion.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Christian Hartmann]

> | While you are at it, why don't you just fork the portage tree? By
> | doing so you would have the freedom to do whatever you want to do
> | without keeping gentoo busy reading your mails.

> Know why this thread's so big? People like you posting crap to it and
> interfering with what would otherwise be a technical discussion.

That actually was a serious question. But you and your gang are good in 
avoiding answering questions that you are not comfortable with.

"People with different views are not welcome. Please move along. Thanks."

-- 
Christian Hartmann
http://www.gentoo.org/~ian/

PGP Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865
Key fingerprint = 4544 EC0C BAE4 216F 5981  7F95 2154 E5EE 692A 4865

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 18:19, Ciaran McCreesh wrote:
>
> Know why this thread's so big? People like you posting crap to it and
> interfering with what would otherwise be a technical discussion.

It should not be a technical discussion. I am sure that adding a profile to 
the tree is not a technical problem. The problem is how we are going to 
ensure that we keep control over our package manager, and ensure that this 
package manager actually functions acceptably (it or a newer version of it 
working with all packages).

Once paludis shows its stability and fitness to replace portage with a 
reasonable complete featureset I would probably be in favour of having it 
replace portage. At that point a feature spread would certainly be welcome.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Christian Birchinger]

On Wed, May 17, 2006 at 05:54:36PM +0200, Christian Hartmann wrote:
> > Not realistic. It means that any new package manager can't do anything
> > new. I'd also like to point out that you can't upgrade to a new Portage
> > version, install some things, downgrade to an older Portage version and
> > expect things to carry on working.
> 
> This, funnily enough, is what people consider being a fork.
> 
> While you are at it, why don't you just fork the portage tree? By doing so you 
> would have the freedom to do whatever you want to do without keeping gentoo 
> busy reading your mails.

I'm interested so please talk only for yourself and not for
gentoo asa whole. Thanks.

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

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Wed, May 17, 2006 at 04:26:28PM +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 17:11:04 +0200 Paul de Vrieze <pauldv@gentoo.org>
> wrote:
> | Let me clarify my statement. I don't care about candy spinners.
> | Paludis (or any other package manager that is to be integrated into
> | gentoo) should basically be able to allow a level of mix and match.
> | This means that at the initial import, it can be run on any package
> | instead of portage, and the results still be usable for portage
> | (possibly after a conversion stage).
> | 
> | This allows testing out the package manager.
> 
> Not realistic. It means that any new package manager can't do anything
> new. I'd also like to point out that you can't upgrade to a new Portage
> version, install some things, downgrade to an older Portage version and
> expect things to carry on working.

Actually, you can for .54 and 2.1.  The only issue is cache backend 
changeover, but that's minor (--metadata, or let portage regen on it's 
own).

Paludis has to work with the ebuilds that are in the tree now- if it 
becomes official, go nuts, redefine the standards as you like, until 
then it needs to remain ebuild level compatible with portage.

Yes it castrates some of the shineys, but portage suffers the same for 
any non-versioned change.


> | > | - No part of the tree, except those that by nature are paludis
> | > | specific, may require the usage of paludis instead of portage.
> | > | This requirement can only be removed after a decision is made by
> | > | the council to retire portage in favour of paludis.
> | >
> | > Again, insane. EAPI allows ebuilds using things that developers have
> | > been after for years (you know, slot and use deps) to be in the
> | > tree in such a way that they appear masked to Portage. That's a
> | > large part of the point of EAPI.
> | 
> | Let's make clear why I put this in. Basically I am of the opinion
> | that until a decision is made to make (in this case) paludis the
> | primary package manager, all official packages should work with
> | portage. Package masked packages are not considered official.
> 
> What of EAPI masked packages?
> 
> The same situation will occur when newer Portage versions supporting
> newer EAPIs are released into p.mask or ~arch. Some packages will end
> up relying upon something that isn't the stable package manager.

One concern here- EAPI was added to version the ebuild format- as 
such, *everyone involved* should be defining the new EAPI.  Defining 
one in one project, and having it end up in the tree is a no go.

Well aware I used EAPI="prefix" for the prefix branch, but that also 
was for testing.  It has not, nor will it ever touch the tree till 
when it's agreed upon by folks also.

~harring

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

[gentoo-dev] Re: Paludis and Profiles

[Duncan]

Paul de Vrieze <pauldv@gentoo.org> posted
200605171711.10418.pauldv@gentoo.org, excerpted below, on  Wed, 17 May
2006 17:11:04 +0200:

> Let's make clear why I put this in. Basically I am of the opinion that 
> until a decision is made to make (in this case) paludis the primary 
> package manager, all official packages should work with portage. Package 
> masked packages are not considered official.

Wasn't it stated that the mechanism paludis uses to hide ebuilds that
won't work in portage from portage is to mask them to it?

IOW, this is already the way it is being handled.  If masked packages
aren't official, and ebuilds that require features only in paludis are
masked as far as portage is concerned, then that checkbox can be checked
off.

-- 
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: Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 17:55, Duncan wrote:
> Paul de Vrieze <pauldv@gentoo.org> posted
> 200605171711.10418.pauldv@gentoo.org, excerpted below, on  Wed, 17 May
>
> 2006 17:11:04 +0200:
> > Let's make clear why I put this in. Basically I am of the opinion that
> > until a decision is made to make (in this case) paludis the primary
> > package manager, all official packages should work with portage. Package
> > masked packages are not considered official.
>
> Wasn't it stated that the mechanism paludis uses to hide ebuilds that
> won't work in portage from portage is to mask them to it?
>
> IOW, this is already the way it is being handled.  If masked packages
> aren't official, and ebuilds that require features only in paludis are
> masked as far as portage is concerned, then that checkbox can be checked
> off.

No, these packages are available to paludis, but not to portage. Basically 
making a case for the use of paludis. I don't think that the decision to 
replace portage should be made in that way.

Please note that what I say is not specific to paludis. Paludis is here just a 
name for any package management contender.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Re: Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 21:17:55 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> No, these packages are available to paludis, but not to portage.
> Basically making a case for the use of paludis. I don't think that
> the decision to replace portage should be made in that way.

To reiterate here, we're not proposing introducing any paludis-specific
features into ebuilds. Only profiles, and those profiles wouldn't
provide anything that would provide users who wouldn't otherwise want
to use paludis with any incentive to switch.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 21:44, Stephen Bennett wrote:
> On Wed, 17 May 2006 21:17:55 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > No, these packages are available to paludis, but not to portage.
> > Basically making a case for the use of paludis. I don't think that
> > the decision to replace portage should be made in that way.
>
> To reiterate here, we're not proposing introducing any paludis-specific
> features into ebuilds. Only profiles, and those profiles wouldn't
> provide anything that would provide users who wouldn't otherwise want
> to use paludis with any incentive to switch.

I know. I wanted to make clear the requirements I have that must be met 
accomodation for a specific package manager can be made in the tree. This 
holds for paludis. If these requirements are not met, the profile should 
not be added.

Up to now I have not been convinced that paludis meets those requirements, 
nor that my requirements are invalid. As such I don't think the profile 
should be added.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Wed, May 17, 2006 at 02:57:05PM +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 12:04:33 +0200 Paul de Vrieze <pauldv@gentoo.org>
> wrote:
> | - Paludis must be able to handle a standard portage /var/db/pkg tree.
> | This means that paludis can read it, and write it. Enabling mixing
> | portage and paludis up to some degree.
> 
> Paludis can read a Portage-generated VDB. Portage can't read a
> Paludis-generated VDB, because Paludis has more features.

What features?  You're tracking CONFIG_PROTECT_*, and saving a copy of 
the eclass (icky solution, but we've discussed that in the past).

Beyond that?


> | - Paludis must work with all current ebuilds, 
> 
> Portage does not work with all current ebuilds.

Name a few please, ones that are portage incompatibility rather then 
"ebuild no longer works against other ebuilds in the tree".  Can't do 
anything about the latter, but the former without proof is fud.


> | and support all features of portage. 
> 
> That's insane. Why should we support Portage-style 'candy' spinners?

I'd expect he's talking more about stuff like having an ebuild 
binary/script for walking the phases of an ebuild for development.


> | This includes recognition of EAPI
> 
> Funnily enough, unlike Portage, Paludis has full EAPI handling.

Please clarify on the "full"- since portage relies on EAPI protection 
already, any issues you see with it's implementation I'd love to know.


> | and no renaming of the variables used.
> 
> Why should Paludis emulate Portage internals that no-one uses?

Moot issue, as I pointed out, dev-lang/perl (and others) are affected 
by it (so someone uses it).

Additionally, you went and commited the vars into paludis (doing 
exactly what I said to do), thank you- lets avoid the 5 emails back 
and forth in the future however please...

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Benjamin Judas]

That whole discussion reminds me of a word we have in the german language: 
"Kindergarten".

http://gallery.benjamin-judas.de/albums/funnystuff/arg.jpg

So can these peope who intend to leave the project stop making noise and 
simply leave instead of putting the cat among the pigeons?

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 11:13:09 -0700 Brian Harring <ferringb@gmail.com>
wrote:
| > Paludis can read a Portage-generated VDB. Portage can't read a
| > Paludis-generated VDB, because Paludis has more features.
| 
| What features?  You're tracking CONFIG_PROTECT_*, and saving a copy
| of the eclass (icky solution, but we've discussed that in the past).
| 
| Beyond that?

Right now, the biggie is virtuals. Attempting to unmerge a virtual that
was installed via Paludis will confuse the heck out of Portage. There's
also the whole "handling symlink / directory mismatches" issue, which
will cause Portage to incorrectly unmerge some Paludis-installed things
(and, for that matter, some Portage-installed things).

| > | - Paludis must work with all current ebuilds, 
| > 
| > Portage does not work with all current ebuilds.
| 
| Name a few please, ones that are portage incompatibility rather then 
| "ebuild no longer works against other ebuilds in the tree".  Can't do 
| anything about the latter, but the former without proof is fud.

We went over this already. Remember webapp.eclass?

| > | and support all features of portage. 
| > 
| > That's insane. Why should we support Portage-style 'candy' spinners?
| 
| I'd expect he's talking more about stuff like having an ebuild 
| binary/script for walking the phases of an ebuild for development.

Heh. You keep on picking out things that you think will be difficult to
implement.

| > | This includes recognition of EAPI
| > 
| > Funnily enough, unlike Portage, Paludis has full EAPI handling.
| 
| Please clarify on the "full"- since portage relies on EAPI protection 
| already, any issues you see with it's implementation I'd love to know.

Portage still relies upon being able to source ebuilds, even if their
EAPI isn't supported.

| Additionally, you went and commited the vars into paludis (doing 
| exactly what I said to do), thank you- lets avoid the 5 emails back 
| and forth in the future however please...

Yes, we now have ~15 lines of useless code. But if that's what it takes
to make you happy...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Wed, May 17, 2006 at 07:44:16PM +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 11:13:09 -0700 Brian Harring <ferringb@gmail.com>
> wrote:
> | > Paludis can read a Portage-generated VDB. Portage can't read a
> | > Paludis-generated VDB, because Paludis has more features.
> | 
> | What features?  You're tracking CONFIG_PROTECT_*, and saving a copy
> | of the eclass (icky solution, but we've discussed that in the past).
> | 
> | Beyond that?
> 
> Right now, the biggie is virtuals. Attempting to unmerge a virtual that
> was installed via Paludis will confuse the heck out of Portage. There's
> also the whole "handling symlink / directory mismatches" issue, which
> will cause Portage to incorrectly unmerge some Paludis-installed things
> (and, for that matter, some Portage-installed things).

Clarify on virtuals please.  Unless you're mangling the data for 
sym/dir, that's an unmerge time decision (as such it's not vdb data 
specific).


> | > | - Paludis must work with all current ebuilds, 
> | > 
> | > Portage does not work with all current ebuilds.
> | 
> | Name a few please, ones that are portage incompatibility rather then 
> | "ebuild no longer works against other ebuilds in the tree".  Can't do 
> | anything about the latter, but the former without proof is fud.
> 
> We went over this already. Remember webapp.eclass?

Nope.  Assume I'm stupid, don't ask a question when I ask for an 
answer, just state it please- saves both you and I time.

Do recall they were triggering merge -C calls on their own, but that's 
not portage incompatibility as much as doing something dumb...


> | > | and support all features of portage. 
> | > 
> | > That's insane. Why should we support Portage-style 'candy' spinners?
> | 
> | I'd expect he's talking more about stuff like having an ebuild 
> | binary/script for walking the phases of an ebuild for development.
> 
> Heh. You keep on picking out things that you think will be difficult to
> implement.

Ebuild is easy- I'm pointing at it because the local env issue should 
rear it's head there.  It's also a tool that ebuild devs rely on 
fairly heavily for debugging, as such two birds one stone (locals 
issue you get to investigate closer, and you flesh paludis out 
further).


> | > | This includes recognition of EAPI
> | > 
> | > Funnily enough, unlike Portage, Paludis has full EAPI handling.
> | 
> | Please clarify on the "full"- since portage relies on EAPI protection 
> | already, any issues you see with it's implementation I'd love to know.
> 
> Portage still relies upon being able to source ebuilds, even if their
> EAPI isn't supported.

Paludis doesn't?

Related, doc this stuff out please.  Portage differences doc you've 
got is more "we're better cause of xyz"- which is fine, but a low 
level "this is what we do differently" (metadata/security fex) would 
at least allow the possibility of folks being on the same page.


> | Additionally, you went and commited the vars into paludis (doing 
> | exactly what I said to do), thank you- lets avoid the 5 emails back 
> | and forth in the future however please...
> 
> Yes, we now have ~15 lines of useless code. But if that's what it takes
> to make you happy...

Makes that perl patch behave properly for security bug, so yes, it's 
progress- thank you.

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 12:06:09 -0700 Brian Harring <ferringb@gmail.com>
wrote:
| Clarify on virtuals please.  Unless you're mangling the data for 
| sym/dir, that's an unmerge time decision (as such it's not vdb data 
| specific).

We're faking new-style virtuals for old-style virtuals, so things end
up in vdb that don't have an associated 'real' ebuild. Portage can't
unmerge them, and it has some trouble with the reduced-content entries
for these too.

| > We went over this already. Remember webapp.eclass?
| 
| Nope.  Assume I'm stupid, don't ask a question when I ask for an 
| answer, just state it please- saves both you and I time.
| 
| Do recall they were triggering merge -C calls on their own, but
| that's not portage incompatibility as much as doing something dumb...

And that's exactly it. At what point does something stop being API and
start being "someone is doing illegal things with internals"?

| Ebuild is easy- I'm pointing at it because the local env issue should 
| rear it's head there.  It's also a tool that ebuild devs rely on 
| fairly heavily for debugging, as such two birds one stone (locals 
| issue you get to investigate closer, and you flesh paludis out 
| further).

Actually, I was planning to handle that one by BREAK_FUNCTIONS (name
sucks and is not final), which is kinda like SKIP_FUNCTIONS but rather
than skipping, launches an interactive shell.

| > Portage still relies upon being able to source ebuilds, even if
| > their EAPI isn't supported.
| 
| Paludis doesn't?

Nope. Paludis can sanely (as in, treat as EAPI masked) handle ebuilds
that bash can't parse. This paves the way for XML-based ebuilds, which
as we all know is a critical feature required for enterprise support.

| Related, doc this stuff out please.  Portage differences doc you've 
| got is more "we're better cause of xyz"- which is fine, but a low 
| level "this is what we do differently" (metadata/security fex) would 
| at least allow the possibility of folks being on the same page.

Yeah, that's something that would be useful. I was trying to get spb to
do it...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Wed, May 17, 2006 at 08:50:32PM +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 12:06:09 -0700 Brian Harring <ferringb@gmail.com>
> wrote:
> | Clarify on virtuals please.  Unless you're mangling the data for 
> | sym/dir, that's an unmerge time decision (as such it's not vdb data 
> | specific).
> 
> We're faking new-style virtuals for old-style virtuals, so things end
> up in vdb that don't have an associated 'real' ebuild. Portage can't
> unmerge them, and it has some trouble with the reduced-content entries
> for these too.

Instead of on the fly generation of the virtuals pkgs (as 
pkgcore/portage do), you've flattened them into an actual on disk vdb 
entry?

Re: incompatibility, that can be dealt with by generating a fake 
ebuild- already generate an env from the looks of it (not seeing 
anything in RDEPEND/DEPEND however).


> | > We went over this already. Remember webapp.eclass?
> | 
> | Nope.  Assume I'm stupid, don't ask a question when I ask for an 
> | answer, just state it please- saves both you and I time.
> | 
> | Do recall they were triggering merge -C calls on their own, but
> | that's not portage incompatibility as much as doing something dumb...
> 
> And that's exactly it. At what point does something stop being API and
> start being "someone is doing illegal things with internals"?

Common sense.  Paludis wouldn't like what they were doing any more 
then pkgcore nor portage- modification of a node cannot cause unstated 
dependency changes, what they were doing was going outside the 
constant metadata rules binding all ebuild supporting pkg managers 
(well, the ones that don't want the 100-400x hit from lacking a 
metadata cache at least).

A real example of where portage doesn't support an ebuild in the 
tree would be welcome (as stated, if it exists it needs fixing).


> | Ebuild is easy- I'm pointing at it because the local env issue should 
> | rear it's head there.  It's also a tool that ebuild devs rely on 
> | fairly heavily for debugging, as such two birds one stone (locals 
> | issue you get to investigate closer, and you flesh paludis out 
> | further).
> 
> Actually, I was planning to handle that one by BREAK_FUNCTIONS (name
> sucks and is not final), which is kinda like SKIP_FUNCTIONS but rather
> than skipping, launches an interactive shell.

Did something similar with ebuild-shell- folks for the most part liked 
it.

Meanwhile... get cracking, you'll see far more local assumptions 
transitioning between phases then transitioning between groupped merge 
phases -> groupped unmerge phases


> | > Portage still relies upon being able to source ebuilds, even if
> | > their EAPI isn't supported.
> | 
> | Paludis doesn't?
> 
> Nope. Paludis can sanely (as in, treat as EAPI masked) handle ebuilds
> that bash can't parse. This paves the way for XML-based ebuilds, which
> as we all know is a critical feature required for enterprise support.

'Cept EAPI was specifically targeted at bash based ebuilds only.  
Alternative formats (non bash fex), expected folks to solve that issue 
themselves (since I didn't see a sane general solution to it).

For what EAPI is defined as, portage supports it fully.


> | Related, doc this stuff out please.  Portage differences doc you've 
> | got is more "we're better cause of xyz"- which is fine, but a low 
> | level "this is what we do differently" (metadata/security fex) would 
> | at least allow the possibility of folks being on the same page.
> 
> Yeah, that's something that would be useful. I was trying to get spb to
> do it...

I'd suggest it as priority- it's really not all that fun arguging over 
details lifted from scanning the code, and getting into terminology 
wars.

Get the doc up, folks can evaluate what the actual support costs for 
paludis are vs assumptions/guesses.

~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 13:43:04 -0700 Brian Harring <ferringb@gmail.com>
wrote:
| Instead of on the fly generation of the virtuals pkgs (as 
| pkgcore/portage do), you've flattened them into an actual on disk vdb 
| entry?

Not really. A fake package is generated for the virtual (rather than
just renaming it to another package), and that gets installed into VDB.

| Re: incompatibility, that can be dealt with by generating a fake 
| ebuild- already generate an env from the looks of it (not seeing 
| anything in RDEPEND/DEPEND however).

Would still confuse Portage somewhat, at least whilst people still use
old style virtuals.

| > And that's exactly it. At what point does something stop being API
| > and start being "someone is doing illegal things with internals"?
| 
| Common sense.

And it's common sense that we've been using all along on the API issue.

| Did something similar with ebuild-shell- folks for the most part
| liked it.
| 
| Meanwhile... get cracking, you'll see far more local assumptions 
| transitioning between phases then transitioning between groupped
| merge phases -> groupped unmerge phases

*shrug* If you want that feature in a hurry, you're more than
welcome to submit a patch. Otherwise it's considered less important
than user mirrors, binaries, sdepend etc. And, uh, the local vars will
still work just fine even with break functions.

| 'Cept EAPI was specifically targeted at bash based ebuilds only.  
| Alternative formats (non bash fex), expected folks to solve that
| issue themselves (since I didn't see a sane general solution to it).
| 
| For what EAPI is defined as, portage supports it fully.

Sure, no-one sane is going to start using XML ebuilds. They might,
however, reasonably want the behaviour of 'inherit' to change.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 20:44, Ciaran McCreesh wrote:
> Portage still relies upon being able to source ebuilds, even if their
> EAPI isn't supported.

Currently, nothing except the ability to parse bash directly would make it 
otherwise. Against my advise, there are no restrictions upon the EAPI 
variable. As such EAPI can not reliably be determined without understanding 
(or being) bash.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 21:22:28 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| On Wednesday 17 May 2006 20:44, Ciaran McCreesh wrote:
| > Portage still relies upon being able to source ebuilds, even if
| > their EAPI isn't supported.
| 
| Currently, nothing except the ability to parse bash directly would
| make it otherwise. Against my advise, there are no restrictions upon
| the EAPI variable. As such EAPI can not reliably be determined
| without understanding (or being) bash.

Not exactly true. There's nothing to stop a package manager from
gracefully handling not even being able to source the ebuild. The way
Paludis handles this is to create fake version metadata for weird
ebuilds with EAPI set to "UNKNOWN". It's not perfect, but it avoids any
overly crazy behaviour.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 21:49, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 21:22:28 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | On Wednesday 17 May 2006 20:44, Ciaran McCreesh wrote:
> | > Portage still relies upon being able to source ebuilds, even if
> | > their EAPI isn't supported.
> |
> | Currently, nothing except the ability to parse bash directly would
> | make it otherwise. Against my advise, there are no restrictions upon
> | the EAPI variable. As such EAPI can not reliably be determined
> | without understanding (or being) bash.
>
> Not exactly true. There's nothing to stop a package manager from
> gracefully handling not even being able to source the ebuild. The way
> Paludis handles this is to create fake version metadata for weird
> ebuilds with EAPI set to "UNKNOWN". It's not perfect, but it avoids any
> overly crazy behaviour.

This is not the standard, nor what portage does. It is what portage should 
do, but not what it does. It would have been far preferable if doing an 
egrep on "^EAPI" would just be enough, but this is not true. EAPI can be 
defined even by EAPI="${PV}" (I know it is silly, but allowed).

My concern is not what paludis does, but what portage does. This means 
that technically paludis can not support all EAPI cases properly (except 
bailing out when parsing fails).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 11:52:49 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| This is not the standard, nor what portage does. 

Portage has a bug that causes it to die a horrible death if ebuilds are
not source-compatible. We do not emulate this bug, because there is no
useful reason to do so and because handling it properly is only another
half dozen lines of code.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 12:04 +0200, Paul de Vrieze wrote:
> - It would be greatly beneficial if paludis would create and use .tbz2
>   packages, but this is not essential.

It *is* essential if paludis were to ever be used for release building.
Otherwise, it isn't required.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 10:57:55 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| On Wed, 2006-05-17 at 12:04 +0200, Paul de Vrieze wrote:
| > - It would be greatly beneficial if paludis would create and
| > use .tbz2 packages, but this is not essential.
| 
| It *is* essential if paludis were to ever be used for release
| building. Otherwise, it isn't required.

No, support for *some* kind of binary package format is necessary.
Support for Portage .tbz2 packages is pointless.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 16:09 +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 10:57:55 -0400 Chris Gianelloni
> <wolf31o2@gentoo.org> wrote:
> | On Wed, 2006-05-17 at 12:04 +0200, Paul de Vrieze wrote:
> | > - It would be greatly beneficial if paludis would create and
> | > use .tbz2 packages, but this is not essential.
> | 
> | It *is* essential if paludis were to ever be used for release
> | building. Otherwise, it isn't required.
> 
> No, support for *some* kind of binary package format is necessary.
> Support for Portage .tbz2 packages is pointless.

I'm sorry, but please don't tell me how things work within my project
when you either don't have a clue, which I know isn't the case, or are
simply ignoring the facts to match what you want to believe.

We ship .tbz2 files on our GRP release media.

Until we either:

a) stop shipping .tbz2 files

-or-

b) switch to paludis support only

The Gentoo release media can *not* be built with Paludis, as it does not
have support for *all* of the portions of the release media that we
currently build.  This is a simple fact that cannot be disputed.  You
can build *portions* of a release, but not the entire thing.  Also, with
an incompatible VDB, the point is moot, anyway, as all of the release
building tools currently require a portage-compatible VDB.

I've been only pointing out things that I consider from a technical or
policy basis.  Please don't go around trying to make it out like I'm
wrong about a process that *I* determine, just to make your package
manager look better.

It can *not* be used to build a Gentoo release at this time.

You will notice that *nowhere* did I say anything about this being any
kind of blocker for paludis being in the tree, or any paludis profiles,
only that it is a blocker for it ever being used for building our
releases, without us deciding to change *what* we release.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 12:05:23 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| We ship .tbz2 files on our GRP release media.
| 
| Until we either:
| 
| a) stop shipping .tbz2 files
| 
| -or-
| 
| b) switch to paludis support only

Which is a rather large difference from what you said originally. It's
also utterly untrue, given how easy it would be to do installs the
non-stage-based way using Paludis. That's one of the many reasons we're
not going to be using the tbz2 format.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 17:29 +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 12:05:23 -0400 Chris Gianelloni
> <wolf31o2@gentoo.org> wrote:
> | We ship .tbz2 files on our GRP release media.
> | 
> | Until we either:
> | 
> | a) stop shipping .tbz2 files
> | 
> | -or-
> | 
> | b) switch to paludis support only
> 
> Which is a rather large difference from what you said originally. It's

No.  It isn't.  I said that it can not build a Gentoo release, and
paludis can not.[1]  Are you trying to tell me that I am wrong and that
paludis *can* build a Gentoo release?  I'm really interested to hear
what magic you have used to distort reality to make this possible.

> also utterly untrue, given how easy it would be to do installs the
> non-stage-based way using Paludis. That's one of the many reasons we're
> not going to be using the tbz2 format.

What you said has *no* bearing *whatsoever* on whether or not paludis
can build a Gentoo release.

Are you really going to insist on trying this approach with this
conversation?  I say that paludis can not be used to build a Gentoo
release, and your answer is that it would be easy to *not* build a
Gentoo release?  Huh?

I'm sorry, but what the hell does that have to do with *anything* that I
am saying?

How about I make this a bit more directed, then?

#1. Can paludis work with catalyst?
#2. Can paludis build all of the release materials required by the
Release Engineering release guidelines?
#3. Can paludis build a portage-compatible VDB that can be used by the
Gentoo Linux Installer?

If it can not do *any* of these three things, then it CAN NOT build a
Gentoo release.  There's no smooth talking or circular reasoning way
around this simple FACT.

All that you have succeeded in doing is alienating me from this
discussion by completely ignoring everything that I have been saying to
try to push... whatever it is that you're trying to push... as fact.
I'm sorry, but you've lost any support that you might have had from me
on this simply by your refusal to even speak on the topics which I have
brought up.  I really don't understand how ignoring points brought up
that would help facilitate something that you want does anything to
further your goals, but that seems to be your way of thinking.

Good day.

[1] http://www.gentoo.org/proj/en/releng/docs/release_guidelines.xml

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 14:12:52 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| No.  It isn't.  I said that it can not build a Gentoo release, and
| paludis can not.[1]  Are you trying to tell me that I am wrong and
| that paludis *can* build a Gentoo release?  I'm really interested to
| hear what magic you have used to distort reality to make this
| possible.

At present, no, since we haven't implemented non-tbz2 binaries.

| #1. Can paludis work with catalyst?

No. Nor will it ever, nor will it need to.

| #2. Can paludis build all of the release materials required by the
| Release Engineering release guidelines?

No. Nor will it ever, nor will it need to.

| #3. Can paludis build a portage-compatible VDB that can be used by the
| Gentoo Linux Installer?

No. Nor will it ever, nor will it need to.

Your claim, specifically, was "It *is* essential if paludis were to
ever be used for release building.". There is more than one way to skin
a cat, and some of those ways don't involve getting blood all over the
floor.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 20:50, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 14:12:52 -0400 Chris Gianelloni
>
> <wolf31o2@gentoo.org> wrote:
> | No.  It isn't.  I said that it can not build a Gentoo release, and
> | paludis can not.[1]  Are you trying to tell me that I am wrong and
> | that paludis *can* build a Gentoo release?  I'm really interested to
> | hear what magic you have used to distort reality to make this
> | possible.
>
> At present, no, since we haven't implemented non-tbz2 binaries.
>
> | #1. Can paludis work with catalyst?
>
> No. Nor will it ever, nor will it need to.

Am I correct in reading this like you will implement a catalyst replacement?

> | #2. Can paludis build all of the release materials required by the
> | Release Engineering release guidelines?
>
> No. Nor will it ever, nor will it need to.

Will you then instead try to create new guidelines that do result into 
development of releases?

>
> | #3. Can paludis build a portage-compatible VDB that can be used by the
> | Gentoo Linux Installer?
>
> No. Nor will it ever, nor will it need to.

Why will it not need to? Usage and support of paludis would be a lot greater 
it it could work (with limited feature perhaps) on a portage compatible VDB. 
You might work with the portage team to have portage be aware of extensions 
in the VDB and handle them smartly (ignore them?). At that point paludis 
could offer extra features while being still portage compatible.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 21:30:13 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| > | #1. Can paludis work with catalyst?
| >
| > No. Nor will it ever, nor will it need to.
| 
| Am I correct in reading this like you will implement a catalyst
| replacement?

The plan, which may be full of holes, may change and may just be me
being crazy, is to replace using a stage with something like:

paludis --config-suffix install --install system

which will then go off and grab the relevant binary packages from a
remote location and merge them onto ROOT. Being able to do something
along these lines is a) one of several reasons for --config-suffix and
b) a large part of why I don't want to use the Portage tbz2 format,
where metadata and contents aren't separated.

| > | #2. Can paludis build all of the release materials required by the
| > | Release Engineering release guidelines?
| >
| > No. Nor will it ever, nor will it need to.
| 
| Will you then instead try to create new guidelines that do result
| into development of releases?

Assuming the above ends up not being insane, then yes.

| > | #3. Can paludis build a portage-compatible VDB that can be used
| > | by the Gentoo Linux Installer?
| >
| > No. Nor will it ever, nor will it need to.
| 
| Why will it not need to? Usage and support of paludis would be a lot
| greater it it could work (with limited feature perhaps) on a portage
| compatible VDB. You might work with the portage team to have portage
| be aware of extensions in the VDB and handle them smartly (ignore
| them?). At that point paludis could offer extra features while being
| still portage compatible.

I'm pretty sure it would be easier to just not use anything in the
installer that relies upon VDB when using Paludis. The installer code
is flexible enough to make this not tooooo tricky.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 20:55 +0100, Ciaran McCreesh wrote:
> The plan, which may be full of holes, may change and may just be me
> being crazy, is to replace using a stage with something like:

OK.  So not only are you planning on replacing portage, you're planning
on replacing Release Engineering.  Thanks, but we are not interested.

> paludis --config-suffix install --install system
> 
> which will then go off and grab the relevant binary packages from a
> remote location and merge them onto ROOT. Being able to do something
> along these lines is a) one of several reasons for --config-suffix and
> b) a large part of why I don't want to use the Portage tbz2 format,
> where metadata and contents aren't separated.

Remote location, huh?  What about non-networked installations?

> | > | #2. Can paludis build all of the release materials required by the
> | > | Release Engineering release guidelines?
> | >
> | > No. Nor will it ever, nor will it need to.
> | 
> | Will you then instead try to create new guidelines that do result
> | into development of releases?
> 
> Assuming the above ends up not being insane, then yes.

Which would have to be accepted by the Release Engineering project.
Perhaps this point has been lost on you up until now.

> | > | #3. Can paludis build a portage-compatible VDB that can be used
> | > | by the Gentoo Linux Installer?
> | >
> | > No. Nor will it ever, nor will it need to.
> | 
> | Why will it not need to? Usage and support of paludis would be a lot
> | greater it it could work (with limited feature perhaps) on a portage
> | compatible VDB. You might work with the portage team to have portage
> | be aware of extensions in the VDB and handle them smartly (ignore
> | them?). At that point paludis could offer extra features while being
> | still portage compatible.
> 
> I'm pretty sure it would be easier to just not use anything in the
> installer that relies upon VDB when using Paludis. The installer code
> is flexible enough to make this not tooooo tricky.

You mean like *all* of the GRP-handling code?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 16:55:17 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| On Wed, 2006-05-17 at 20:55 +0100, Ciaran McCreesh wrote:
| > The plan, which may be full of holes, may change and may just be me
| > being crazy, is to replace using a stage with something like:
| 
| OK.  So not only are you planning on replacing portage, you're
| planning on replacing Release Engineering.  Thanks, but we are not
| interested.

Not so much replacing as removing the need for.

| > paludis --config-suffix install --install system
| > 
| > which will then go off and grab the relevant binary packages from a
| > remote location and merge them onto ROOT. Being able to do something
| > along these lines is a) one of several reasons for --config-suffix
| > and b) a large part of why I don't want to use the Portage tbz2
| > format, where metadata and contents aren't separated.
| 
| Remote location, huh?  What about non-networked installations?

Remote location can be somewhere else on a filesystem.

| > Assuming the above ends up not being insane, then yes.
| 
| Which would have to be accepted by the Release Engineering project.
| Perhaps this point has been lost on you up until now.

*shrug* Not an issue. The whole thing removes the need for traditional
releases.

| > I'm pretty sure it would be easier to just not use anything in the
| > installer that relies upon VDB when using Paludis. The installer
| > code is flexible enough to make this not tooooo tricky.
| 
| You mean like *all* of the GRP-handling code?

Also no longer necessary.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 19:50 +0100, Ciaran McCreesh wrote:
> | #1. Can paludis work with catalyst?
> 
> No. Nor will it ever, nor will it need to.

To be used for building a Gentoo release, yes it will.

> 
> | #2. Can paludis build all of the release materials required by the
> | Release Engineering release guidelines?
> 
> No. Nor will it ever, nor will it need to.

To be used for building a Gentoo release, yes it will.

> 
> | #3. Can paludis build a portage-compatible VDB that can be used by the
> | Gentoo Linux Installer?
> 
> No. Nor will it ever, nor will it need to.

To be used for building a Gentoo release, yes it will.

> Your claim, specifically, was "It *is* essential if paludis were to
> ever be used for release building.". There is more than one way to skin
> a cat, and some of those ways don't involve getting blood all over the
> floor.

Sure, there's more than one way to build a release.  However, there's
only *one* way to build an official Gentoo release.  It sounds like
Paludis falls short on this 100%.

My recommendation, as Release Engineering Strategic Lead, is that no
profiles be added to the tree, nor any modifications be made to any
current profile, including base or the profiles directory, until such
time that Paludis is actually a usable package manager for building a
Gentoo release.  I also recommend that the package is masked in all
Gentoo profiles where a release is built against, since again, it is
100% incompatible and upstream has now said that they have no intentions
on making it compatible.  As I see it, the original question posed to
this list is now a non-issue.  It will *never* be portage compatible
enough, according to the lead developer, to ever be usable as a portage
replacement or alternative.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Thomas Cort]

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

On Wed, 17 May 2006 15:48:04 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> I also recommend that the package is masked in all
> Gentoo profiles where a release is built against, since again, it is
> 100% incompatible and upstream has now said that they have no intentions
> on making it compatible.

rpm, stow, and dpkg are 100% incompatible with portage and I'm fairly certain that upstream has no intentions of making them compatible, yet they are in the tree and stable on many arches. Are you also suggesting that we mask them too?

~tcort

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

Re: [gentoo-dev] Paludis and Profiles

[Diego 'Flameeyes' Pettenò]

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

On Wednesday 17 May 2006 18:26, Thomas Cort wrote:
> rpm, stow, and dpkg are 100% incompatible with portage and I'm fairly
> certain that upstream has no intentions of making them compatible, yet they
> are in the tree and stable on many arches. Are you also suggesting that we
> mask them too?
And you don't see profiles that uses any of them. Nor you'll ever see them. 
They are there mainly for developers' peace when they have to inspect RPMs or 
DEBs (I actually do that often).

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 16:26 +0000, Thomas Cort wrote:
> On Wed, 17 May 2006 15:48:04 -0400
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > I also recommend that the package is masked in all
> > Gentoo profiles where a release is built against, since again, it is
> > 100% incompatible and upstream has now said that they have no intentions
> > on making it compatible.
> 
> rpm, stow, and dpkg are 100% incompatible with portage and I'm fairly certain that upstream has no intentions of making them compatible, yet they are in the tree and stable on many arches. Are you also suggesting that we mask them too?

What do package managers that don't claim, in any way, to be
portage-compatible have to do with *this* package manager that *does*?

One of the goals of this package is to be a portage
replacement/alternative.

Why do people *insist* on trying to add so many levels of indirection
into their "discussions"?  Do you really think that attempting to
confuse a situation makes it any easier to reach a solution?  Are you
arguing for the sake of arguing?  Perhaps you just like to hear yourself
talk?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Thomas Cort]

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

On Wed, 17 May 2006 17:05:31 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> What do package managers that don't claim, in any way, to be
> portage-compatible have to do with *this* package manager that *does*?

I don't see paludis claiming that it is portage-compatible anywhere on their website. In fact they specifically tell you that it is not compatible. "Do not try to use Paludis and Portage to install things inside the same root. The config and vdb formats are not compatible!"

> Why do people *insist* on trying to add so many levels of indirection
> into their "discussions"? 

Isn't discussing if paludis can build ISOs for a bunch of arches a level of indirection? This thread was originally about adding a profile. The profile doesn't affect anyone who doesn't use it, nor does it require any changes to existing ebuilds or profiles. It adds no work for developers who are not interested. The only additional work load would be to bug wranglers for users who file bugs, and this has already been discussed. Can we please get back on topic. Is there a valid technical reason against adding the profile?

~tcort

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

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 19:38, Thomas Cort wrote:

> Isn't discussing if paludis can build ISOs for a bunch of arches a
> level of indirection? This thread was originally about adding a
> profile. The profile doesn't affect anyone who doesn't use it, nor does
> it require any changes to existing ebuilds or profiles. It adds no work
> for developers who are not interested. The only additional work load
> would be to bug wranglers for users who file bugs, and this has already
> been discussed. Can we please get back on topic. Is there a valid
> technical reason against adding the profile?

The profile is a step in the process of paludis becomming accepted. 
Besides a profile being unneeded at this point, it is also to early to 
provide this level of support to an alternative package maanger. If the 
profile is accepted at this point, it also means that gentoo has accepted 
paludis in some way. This is a bigger way than just having it in the 
tree.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 17:05:31 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| Why do people *insist* on trying to add so many levels of indirection
| into their "discussions"?

Because some people insist upon trying to attack Paludis via FUD and
keep on trying to add in entirely irrelevant 'requirements' that have
nothing to do with the original topic?

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 15:48:04 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| My recommendation, as Release Engineering Strategic Lead, is that no
| profiles be added to the tree, nor any modifications be made to any
| current profile, including base or the profiles directory, until such
| time that Paludis is actually a usable package manager for building a
| Gentoo release.  I also recommend that the package is masked in all
| Gentoo profiles where a release is built against, since again, it is
| 100% incompatible and upstream has now said that they have no
| intentions on making it compatible.  As I see it, the original
| question posed to this list is now a non-issue.  It will *never* be
| portage compatible enough, according to the lead developer, to ever
| be usable as a portage replacement or alternative.

So what you're saying is that until Paludis is called Portage and is
identical to Portage, it's a no go. Which is clearly crazy talk, since
Paludis can already be used to install a system from scratch -- it just
does so differently.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 21:13 +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 15:48:04 -0400 Chris Gianelloni
> <wolf31o2@gentoo.org> wrote:
> | My recommendation, as Release Engineering Strategic Lead, is that no
> | profiles be added to the tree, nor any modifications be made to any
> | current profile, including base or the profiles directory, until such
> | time that Paludis is actually a usable package manager for building a
> | Gentoo release.  I also recommend that the package is masked in all
> | Gentoo profiles where a release is built against, since again, it is
> | 100% incompatible and upstream has now said that they have no
> | intentions on making it compatible.  As I see it, the original
> | question posed to this list is now a non-issue.  It will *never* be
> | portage compatible enough, according to the lead developer, to ever
> | be usable as a portage replacement or alternative.
> 
> So what you're saying is that until Paludis is called Portage and is
> identical to Portage, it's a no go. Which is clearly crazy talk, since
> Paludis can already be used to install a system from scratch -- it just
> does so differently.

See, this is why people have problems having a discussion with you.  You
inject your own ideas and thoughts into their words and beat around the
bush so much that it is impossible to tell what the hell you're actually
trying to say.  Never once did I say that it must be called portage.
Never once did I say that it must support all of the features of
portage.  That is *you* saying that I said something that I have not.
It is you flat out lying.  Quite simply, I'm not surprised.

Here's what I am trying to say plainly.

Paludis does not conform to the Release Engineering guidelines.  It is
*incapable* of producing a Gentoo release.  The authors have expressed
their intentions to *never* perform any actions necessary to work
towards making Paludis capable of producing a Gentoo release.

This is completely unacceptable to Release Engineering, and as such, it
is my recommendation that no support be added to the *portage* tree to
support paludis.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 17:00:10 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| Paludis does not conform to the Release Engineering guidelines.  It is
| *incapable* of producing a Gentoo release.  The authors have expressed
| their intentions to *never* perform any actions necessary to work
| towards making Paludis capable of producing a Gentoo release.

And what has producing a releng-style Gentoo release got to do with
using Paludis as a package manager? That's like saying ZSH shouldn't be
included in the tree until it can be used in place of bash.

| This is completely unacceptable to Release Engineering, and as such,
| it is my recommendation that no support be added to the *portage*
| tree to support paludis.

You mean the *gentoo-x86* tree, right? The only reason some people call
it the 'Portage' tree is that there's not previously been a need to
call it something else.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 23:30, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 17:00:10 -0400 Chris Gianelloni
>
> <wolf31o2@gentoo.org> wrote:
> | Paludis does not conform to the Release Engineering guidelines.  It
> | is *incapable* of producing a Gentoo release.  The authors have
> | expressed their intentions to *never* perform any actions necessary
> | to work towards making Paludis capable of producing a Gentoo release.
>
> And what has producing a releng-style Gentoo release got to do with
> using Paludis as a package manager? That's like saying ZSH shouldn't be
> included in the tree until it can be used in place of bash.

There is only one case in which paludis should be supported by the tree. 
This is when paludis works towards being usable as a portage replacement. 
If the paludis authors do not aim at replacing portage, I suggest them to 
start their own distribution or (fork / derived distro).

When paludis aims to be a viable replacement for portage, it must follow 
the requirements that hold for such a replacement. This means that at 
some point it must be possible to replace portage by paludis in a 
compatible way for all uses, including release engineering. If 
alternative ways to achieve the same better are provided that is also ok. 
A release is something to achieve, not some means to achieve something 
else.

If paludis never wants to replace portage, but wants to be a secondary 
package manager it should not accept ebuilds that portage does not. 
Otherwise it would put itself in the position of a primary package 
manager, while not being capable to do so. Also a secondary package 
manager must work with the portage package database (VDB) in such a way 
that portage can always be used on the system where paludis has been 
used.

> You mean the *gentoo-x86* tree, right? The only reason some people call
> it the 'Portage' tree is that there's not previously been a need to
> call it something else.

The tree. Whose cvs incarnation has been called gentoo-x86 for historical 
reasons.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 12:03:23 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| There is only one case in which paludis should be supported by the
| tree. This is when paludis works towards being usable as a portage
| replacement. If the paludis authors do not aim at replacing portage,
| I suggest them to start their own distribution or (fork / derived
| distro).

Paludis can already be used as a Portage replacement, if one so
desires. It's still kinda rough around the edges, of course.

| When paludis aims to be a viable replacement for portage, it must
| follow the requirements that hold for such a replacement. This means
| that at some point it must be possible to replace portage by paludis
| in a compatible way for all uses, including release engineering. If 
| alternative ways to achieve the same better are provided that is also
| ok. A release is something to achieve, not some means to achieve
| something else.

No, a release is merely a means to the end of installing a system.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Daniel Ostrow]

<snip>
> Your claim, specifically, was "It *is* essential if paludis were to
> ever be used for release building.". There is more than one way to skin
> a cat, and some of those ways don't involve getting blood all over the
> floor.
</snip>

Unfortunately in this case there is only one cat, he has only one skin
and there is only one knife with which to skin him. Chris asked if
paludis can build a release (meaning an official Gentoo release), which
means following the Release Guidelines to the letter. That involves
things that you clearly state that paludis either cannot or will not do.
Your answer boils down to "Paludis can (or will be able to) build
something that would work in a similar fashion to an official Gentoo
release insofar as it has the ability to facilitate an end-user install.
It does not now nor will it ever be able to create a release according
to the Release Guidelines." In effect making your answer "No."

--Dan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 16:12:09 -0400 Daniel Ostrow <dostrow@gentoo.org>
wrote:
| Unfortunately in this case there is only one cat, he has only one skin
| and there is only one knife with which to skin him. Chris asked if
| paludis can build a release (meaning an official Gentoo release),
| which means following the Release Guidelines to the letter.

If you look at it that way (which isn't what he actually asked to begin
with), then the question is "is Paludis identical to Portage?", which
it clearly isn't. A more useful question is "can Paludis give the same
end result as Portage?".

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Tim Yamin]

On Wed, May 17, 2006 at 09:22:45PM +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 16:12:09 -0400 Daniel Ostrow <dostrow@gentoo.org>
> wrote:
> | Unfortunately in this case there is only one cat, he has only one skin
> | and there is only one knife with which to skin him. Chris asked if
> | paludis can build a release (meaning an official Gentoo release),
> | which means following the Release Guidelines to the letter.
> 
> If you look at it that way (which isn't what he actually asked to begin
> with), then the question is "is Paludis identical to Portage?", which
> it clearly isn't. A more useful question is "can Paludis give the same
> end result as Portage?".

So if it can give the same end result, it can be a replacement. So hence
paludis should be able to do what Portage + Catalyst now do. Which you've
not-so-clearly said is not the case; unless paludis has now manifested
the ability to generate bootable ISOs across nine architectures, which
it clearly hasn't. Therefore paludis can not deliver the same end result
as Portage.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Andrew Gaffney]

Tim Yamin wrote:
> So if it can give the same end result, it can be a replacement. So hence
> paludis should be able to do what Portage + Catalyst now do. Which you've
> not-so-clearly said is not the case; unless paludis has now manifested
> the ability to generate bootable ISOs across nine architectures, which
> it clearly hasn't. Therefore paludis can not deliver the same end result
> as Portage.

Last I checked, Portage doesn't have the ability to generate bootable ISOs 
across nine architectures, either :)

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Tim Yamin]

On Wed, May 17, 2006 at 03:49:16PM -0500, Andrew Gaffney wrote:
> Tim Yamin wrote:
> >So if it can give the same end result, it can be a replacement. So hence
> >paludis should be able to do what Portage + Catalyst now do. Which you've
> >not-so-clearly said is not the case; unless paludis has now manifested
> >the ability to generate bootable ISOs across nine architectures, which
> >it clearly hasn't. Therefore paludis can not deliver the same end result
> >as Portage.
> 
> Last I checked, Portage doesn't have the ability to generate bootable ISOs 
> across nine architectures, either :)

Well, if you're going to have a package manager that delivers the same result
as Portage it must therefore work with Catalyst... or it must replace catalyst.
And according to Ciaran:

""
| #1. Can paludis work with catalyst?

No. Nor will it ever, nor will it need to.
""

... hence paludis would be required to do whatever "end result" catalyst
produces (i.e. official release media) for it to be usable as an official
package manager.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 20:56:14 +0000
plasmaroo@gentoo.org (Tim Yamin) wrote:

> Well, if you're going to have a package manager that delivers the
> same result as Portage it must therefore work with Catalyst...

Paludis can produce the same end result as Portage. The reason it won't
work with catalyst is that the interface is different.

Once again, this is going far beyond the scope of the initial
discussion. I'm not saying that Paludis should replace Portage, nor
that it should be an "officially supported package manager". The
question is simply one of whether I can add a top-level paludis profile
without people complaining overmuch, or whether I have to go through
the arch teams and make sub-profiles in 4 different places under
default-linux/.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Tim Yamin]

On Wed, May 17, 2006 at 10:30:10PM +0100, Stephen Bennett wrote:
> On Wed, 17 May 2006 20:56:14 +0000
> plasmaroo@gentoo.org (Tim Yamin) wrote:
> 
> > Well, if you're going to have a package manager that delivers the
> > same result as Portage it must therefore work with Catalyst...
> 
> Paludis can produce the same end result as Portage. The reason it won't
> work with catalyst is that the interface is different.

... so thus you claim it can produce binpkgs (I'm not bothered about the
interface, but the support to produce said binpkg must be there and also
to utilize said binpkg to install things)... and it can't.

> Once again, this is going far beyond the scope of the initial
> discussion. I'm not saying that Paludis should replace Portage, nor
> that it should be an "officially supported package manager". The
> question is simply one of whether I can add a top-level paludis profile
> without people complaining overmuch, or whether I have to go through
> the arch teams and make sub-profiles in 4 different places under
> default-linux/.

Yes, getting this thread back on-topic would be nice.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 21:32:47 +0000 plasmaroo@gentoo.org (Tim Yamin)
wrote:
| On Wed, May 17, 2006 at 10:30:10PM +0100, Stephen Bennett wrote:
| > On Wed, 17 May 2006 20:56:14 +0000
| > plasmaroo@gentoo.org (Tim Yamin) wrote:
| > 
| > > Well, if you're going to have a package manager that delivers the
| > > same result as Portage it must therefore work with Catalyst...
| > 
| > Paludis can produce the same end result as Portage. The reason it
| > won't work with catalyst is that the interface is different.
| 
| ... so thus you claim it can produce binpkgs (I'm not bothered about
| the interface, but the support to produce said binpkg must be there
| and also to utilize said binpkg to install things)... and it can't.

No, we claim that it can install a system (very suckily and messily,
right now, but in the future when we're claiming that it can install a
system *nicely*, it won't be in the slightest bit inelegant).

| Yes, getting this thread back on-topic would be nice.

Then stop taking potshots.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Mike Auty]

Stephen Bennett wrote:
> The
> question is simply one of whether I can add a top-level paludis profile
> without people complaining overmuch, or whether I have to go through
> the arch teams and make sub-profiles in 4 different places under
> default-linux/.

That implies it's going to be added to the tree one way or another.  You
seem to have misplaced the third option of not adding anything to the tree.
	Mike  5:)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 23:30, Stephen Bennett wrote:
> Once again, this is going far beyond the scope of the initial
> discussion. I'm not saying that Paludis should replace Portage, nor
> that it should be an "officially supported package manager". The
> question is simply one of whether I can add a top-level paludis profile
> without people complaining overmuch, or whether I have to go through
> the arch teams and make sub-profiles in 4 different places under
> default-linux/.

Neither option. Making 4 subprofiles is even worse than one toplevel 
profile. The point is however that for a portage replacement there should 
not be any profile changes needed (Or do you think that when pkgcore 
comes about we should have current*3 profiles, just to support each 
package manager?)

Requiring a specific profile change just for a package manager is bad 
design.

Next to this technical argument, adding anything for paludis sends the 
wrong message:
- It says paludis is usable in gentoo. Which it isn't.
- It says that paludis will be at some point supported by gentoo. Which
  decision has not been made yet and can not be made yet as paludis is not
  ready yet.
- It says that other changes to specifically accomodate paludis will be
  made at later points.
- It says that paludis is currently useable. It however is not. An
  installed system can not be converted to or from paludis. Paludis is not
  tested nor testable (requires conversion abilities). Paludis does not
  provide compatibility with current portage, therefore disqualifying
  itself as candidate for portage replacement.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 12:15:07 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| - It says paludis is usable in gentoo. Which it isn't.

Why don't you try it? I think you might find that it is in fact rather
usable. Much more so than some GCC releases and kernels that have their
own profiles in the tree, anyway.

| - It says that paludis is currently useable. It however is not.

Sure it is.

| An installed system can not be converted to or from paludis.

It can be converted *to* Paludis.

| Paludis is not tested nor testable (requires conversion abilities).

Nonsense.

| Paludis does not provide compatibility with current portage, therefore
| disqualifying itself as candidate for portage replacement.

By that argument, future Portage versions aren't compatible with
current Portage, and so are not a candidate for Portage replacement.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 18:19, Ciaran McCreesh wrote:
>
> By that argument, future Portage versions aren't compatible with
> current Portage, and so are not a candidate for Portage replacement.
>
The primary package manager has different standards to adhere to as any other.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 19:47:55 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| On Thursday 18 May 2006 18:19, Ciaran McCreesh wrote:
| > By that argument, future Portage versions aren't compatible with
| > current Portage, and so are not a candidate for Portage replacement.
| >
| The primary package manager has different standards to adhere to as
| any other.

There is no such thing as a primary package manager and using such a
term only serves to distract from what could otherwise be productive
discussion.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 20:03, Ciaran McCreesh wrote:
> On Thu, 18 May 2006 19:47:55 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | On Thursday 18 May 2006 18:19, Ciaran McCreesh wrote:
> | > By that argument, future Portage versions aren't compatible with
> | > current Portage, and so are not a candidate for Portage replacement.
> |
> | The primary package manager has different standards to adhere to as
> | any other.
>
> There is no such thing as a primary package manager and using such a
> term only serves to distract from what could otherwise be productive
> discussion.

Why so. Portage is the one and only (thus primary) package manager for the 
gentoo tree.  It is by itself responsible for the database of installed 
packages. This responsibility can only be held by one package manager at the 
time as multiple databases would create conflicts and / or missing 
information. That means at a system there is a primary package manager. 

The productive discussion is distracted from by your attempts to hamper my 
argumentation by making unsupported accusations against my reasoning.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 20:33:05 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| > There is no such thing as a primary package manager and using such a
| > term only serves to distract from what could otherwise be productive
| > discussion.
| 
| Why so. Portage is the one and only (thus primary) package manager
| for the gentoo tree.  It is by itself responsible for the database of
| installed packages. This responsibility can only be held by one
| package manager at the time as multiple databases would create
| conflicts and / or missing information. That means at a system there
| is a primary package manager. 

Circular argument.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 20:42, Ciaran McCreesh wrote:
> On Thu, 18 May 2006 20:33:05 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | > There is no such thing as a primary package manager and using such a
> | > term only serves to distract from what could otherwise be productive
> | > discussion.
> |
> | Why so. Portage is the one and only (thus primary) package manager
> | for the gentoo tree.  It is by itself responsible for the database of
> | installed packages. This responsibility can only be held by one
> | package manager at the time as multiple databases would create
> | conflicts and / or missing information. That means at a system there
> | is a primary package manager.
>
> Circular argument.

Let me repeat it in primary school language.

A supported statement is one which has the form:

<reason 1> <reason 2> ... <Statement> ... <reason n-1> <reason n>

In short a supported statement has reasons that aim to argue why the statement 
is true.

You say that there is no such a thing as a primary package manager, but fail 
to state any reason (here or in other mails) as to why this is true. Instead 
of arguing why my support is false you just say that I am saying things that 
are not true. This is an unbased accusation.

This last email is close to slander.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 22:27:59 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| > Circular argument.
| 
| Let me repeat it in primary school language.
| 
| A supported statement is one which has the form:
| 
| <reason 1> <reason 2> ... <Statement> ... <reason n-1> <reason n>
| 
| In short a supported statement has reasons that aim to argue why the
| statement is true.

And your definition of a primary package manager is:

<reason 1> <statement> <reason 1>

| You say that there is no such a thing as a primary package manager,
| but fail to state any reason (here or in other mails) as to why this
| is true. Instead of arguing why my support is false you just say that
| I am saying things that are not true. This is an unbased accusation.

No, I am claiming that your entire idea of a primary package manager is
based upon circular logic and is thus invalid. It's like trying to
debate the existence of green happiness -- since the thing the words
describe is meaningless, there's no logical argument to be had.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 22:43, Ciaran McCreesh wrote:
> | You say that there is no such a thing as a primary package manager,
> | but fail to state any reason (here or in other mails) as to why this
> | is true. Instead of arguing why my support is false you just say that
> | I am saying things that are not true. This is an unbased accusation.
>
> No, I am claiming that your entire idea of a primary package manager is
> based upon circular logic and is thus invalid. It's like trying to
> debate the existence of green happiness -- since the thing the words
> describe is meaningless, there's no logical argument to be had.

Then point out the circular reasoning. If you think you can't convince me, 
do it to convince others. Neither of us will have the final say in this.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 20:39:47 +0000 plasmaroo@gentoo.org (Tim Yamin)
wrote:
| So if it can give the same end result, it can be a replacement. So
| hence paludis should be able to do what Portage + Catalyst now do.
| Which you've not-so-clearly said is not the case; unless paludis has
| now manifested the ability to generate bootable ISOs across nine
| architectures, which it clearly hasn't. Therefore paludis can not
| deliver the same end result as Portage.

If that were the argument, that wouldn't be so bad (although remember
that some archs can't use ISOs to install, and so only use Catalyst
things for the stages). On the other hand, ISO building isn't a
priority, since we can nick ISOs from elsewhere.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 21:22 +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 16:12:09 -0400 Daniel Ostrow <dostrow@gentoo.org>
> wrote:
> | Unfortunately in this case there is only one cat, he has only one skin
> | and there is only one knife with which to skin him. Chris asked if
> | paludis can build a release (meaning an official Gentoo release),
> | which means following the Release Guidelines to the letter.
> 
> If you look at it that way (which isn't what he actually asked to begin
> with), then the question is "is Paludis identical to Portage?", which
> it clearly isn't. A more useful question is "can Paludis give the same
> end result as Portage?".

It can not.

Paludis, by your own admission, can not and will not build
portage-compatible binary packages.

This is a simple binary equation.  Can paludis provide a
portage-compatible binary package?  No.  This means it does not give the
same end result.  Period.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 17:01:44 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| This is a simple binary equation.  Can paludis provide a
| portage-compatible binary package?  No.  This means it does not give
| the same end result.  Period.

The desired end result is installing a system. Paludis can do that
already, if you really want, and it will be able to do it much more
elegantly in the future.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Josh Saddler]

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

Ciaran McCreesh wrote:
> The desired end result is installing a system. Paludis can do that
> already, if you really want, and it will be able to do it much more
> elegantly in the future.

Aren't we looking (or trying to look) a *little beyond* just an installed system?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEbMw2rsJQqN81j74RAowoAJwK5QoMAchi/EsDrSMsofM9dI93qwCgsWfu
v1f5qITTOuyHhEk6El3Yb4Q=
=yucm
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 12:34:14 -0700 Josh Saddler <nightmorph@gentoo.org>
wrote:
| Ciaran McCreesh wrote:
| > The desired end result is installing a system. Paludis can do that
| > already, if you really want, and it will be able to do it much more
| > elegantly in the future.
| 
| Aren't we looking (or trying to look) a *little beyond* just an
| installed system?

Oh, sure, it can do ongoing maintenance (upgrading, reinstalling,
installing new things etc) too. But that point isn't contentious.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

OK, since several people have asked what is going to be in this profile
if it gets added, i had in mind something like the following (all
filenames relative to gentoo-x86/profiles/):

===

paludis/deprecated:
# DO NOT USE THIS PROFILE WITH PORTAGE.
# This profile is intended for use with the Paludis package manager,
# and requires features that current Portage versions do not support.
# If you attempt to use it # with Portage, things *WILL* break. You have
# been warned. 
#
# paludis: ignore this
 
paludis/packages:
-*>=sys-apps/portage-2.0.51.22
*sys-apps/paludis
 
paludis/virtuals:
virtual/portage sys-apps/paludis
 
paludis/package.mask:
=sys-libs/glibc-2.4-r1
 
paludis/x86/parent:
../../default-linux/x86/2006.0
..
 
paludis/amd64/parent:
../../default-linux/amd64/2006.0
..
 
<similarly for other arch profiles, if they get added>
<deprecated notice to be duplicated in all subprofiles if necessary>

===

The deprecated notice should address the concerns of those worried
about people switching a Portage system to use one of these profiles,
as it would then spit out a hard-to-miss notice upon attempting to do
anything. Additionally, at present anyone using the sub-profiles with
Portage would get a profile identical to the default-linux ones, due to
Portage only considering the first line in parent.

Possible additions at a later date could involve use.force for profiles
where appropriate (the 'ip28' use flag is an obvious example), as well
as package.use.mask being used for per-package USE combination
restrictions. However, Portage at the moment ignores the files
involved, so they do not affect the issue of Portage attempting to use
one of these profiles.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Mike Frysinger]

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

On Tuesday 16 May 2006 20:42, Stephen Bennett wrote:
> OK, since several people have asked what is going to be in this profile
> if it gets added, i had in mind something like the following

considering this initial profile is a stab in the dark of sorts, i think the 
best way to move forward is to use an overlay much like the BSD stuff does

once profile design has proven itself to stable, it can be moved over to the 
official tree

> (all filenames relative to gentoo-x86/profiles/):

this looks best to me to keep things "separate" ... the arch specific dir can 
pull at the default-linux arch parent just fine
-mike

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

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 02:42, Stephen Bennett wrote:
>
> paludis/packages:
> -*>=sys-apps/portage-2.0.51.22
> *sys-apps/paludis

Is there any reason that portage and paludis can not live together. As 
this basically blocks any kind of migration or backwards compatibility I 
see this as a very serious roadblock to the acceptance of paludis as a 
supported (secondary) package manager.

> The deprecated notice should address the concerns of those worried
> about people switching a Portage system to use one of these profiles,
> as it would then spit out a hard-to-miss notice upon attempting to do
> anything. Additionally, at present anyone using the sub-profiles with
> Portage would get a profile identical to the default-linux ones, due to
> Portage only considering the first line in parent.

With the contents of this profile I see no reason whatsoever to include it 
in the tree. Paludis itself could easilly maintain a blocker on portage. 
The rest is so boilerplate that it has no added benefit of having paludis 
use the normal profiles.

Using the normal profiles would also establish paludis as a possible 
replacement of portage as primary package manager. Refraining from doing 
so disqualifies paludis from becoming a replacement for portage. As the 
only point in adding a secondary package manager is the possible 
replacement of the current primary package manager, I see no point to 
make any paludis directed changes to the tree.

Paludis at this point is just a third party package manager, comparable to 
rpm, and should be treated as such. Paludis could become a secondary 
package manager (waranting limited tree changes) when it has proved 
stability and has taken away all limits that prevent it from replacing 
portage at some point.

If paludis does not aim at replacing portage, including an easy upgrade 
path and long testing, I see no point in using any gentoo resources in 
its support. This includes the pointlessness of making profile changes.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Simon Stelling]

Paul de Vrieze wrote:
> On Wednesday 17 May 2006 02:42, Stephen Bennett wrote:
> 
>>paludis/packages:
>>-*>=sys-apps/portage-2.0.51.22
>>*sys-apps/paludis
> 
> 
> Is there any reason that portage and paludis can not live together. As 
> this basically blocks any kind of migration or backwards compatibility I 
> see this as a very serious roadblock to the acceptance of paludis as a 
> supported (secondary) package manager.

This is not a block. -*>=sys-apps/portage-2.0.51.22 means that the 
depedency on portage is no longer in the system class (base defines it 
as such).

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 12:14:37 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> Using the normal profiles would also establish paludis as a possible 
> replacement of portage as primary package manager. Refraining from
> doing so disqualifies paludis from becoming a replacement for
> portage. As the only point in adding a secondary package manager is
> the possible replacement of the current primary package manager, I
> see no point to make any paludis directed changes to the tree.

Using the normal profiles isn't an option unless they're changed to
include virtual/portage in the system set instead of sys-apps/portage.
That's the key change we're interested in here -- that the system set
not pull in portage when paludis is being used instead.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 13:11, Stephen Bennett wrote:
> On Wed, 17 May 2006 12:14:37 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > Using the normal profiles would also establish paludis as a possible
> > replacement of portage as primary package manager. Refraining from
> > doing so disqualifies paludis from becoming a replacement for
> > portage. As the only point in adding a secondary package manager is
> > the possible replacement of the current primary package manager, I
> > see no point to make any paludis directed changes to the tree.
>
> Using the normal profiles isn't an option unless they're changed to
> include virtual/portage in the system set instead of sys-apps/portage.
> That's the key change we're interested in here -- that the system set
> not pull in portage when paludis is being used instead.

Is there a problem about both of them being there?

I don't see a problem in changing the profiles to include virtual/portage 
though where portage is the default provider. It is a change unrelated to 
paludis, and would allow easier development of any alternative package 
manager.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 13:40:18 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> Is there a problem about both of them being there?

You can't use both on the same ROOT. The VDB format is subtly different.

> I don't see a problem in changing the profiles to include
> virtual/portage though where portage is the default provider. It is a
> change unrelated to paludis, and would allow easier development of
> any alternative package manager.

This could be a viable alternative if the paludis profile is shown to
be a no-go. A seperate profile would make things easier from a
bug-wrangling point of view, since it would be easier to determine when
a bug may be caused by using paludis.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 14:24, Stephen Bennett wrote:
> On Wed, 17 May 2006 13:40:18 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > Is there a problem about both of them being there?
>
> You can't use both on the same ROOT. The VDB format is subtly
> different.

So this would be an effort to prevent users to shoot themselves in the 
foot.
>
> > I don't see a problem in changing the profiles to include
> > virtual/portage though where portage is the default provider. It is a
> > change unrelated to paludis, and would allow easier development of
> > any alternative package manager.
>
> This could be a viable alternative if the paludis profile is shown to
> be a no-go. A seperate profile would make things easier from a
> bug-wrangling point of view, since it would be easier to determine when
> a bug may be caused by using paludis.

At this point I don't see that paludis is ready for such thing. In any 
case I think that optimally a package manager does not require its own 
profile.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 17:13:31 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| At this point I don't see that paludis is ready for such thing.

How would you know?

| In any case I think that optimally a package manager does not require
| its own profile.

Perhaps you should look at how much Portage stuff there is in the
profiles. The Portage-specific things are why Paludis needs its own
profile.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 17:21, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 17:13:31 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | At this point I don't see that paludis is ready for such thing.
>
> How would you know?
>
> | In any case I think that optimally a package manager does not require
> | its own profile.
>
> Perhaps you should look at how much Portage stuff there is in the
> profiles. The Portage-specific things are why Paludis needs its own
> profile.

I couldn't find anything in the "default-linux/x86" profile. Could you 
perhaps point something out for me. I realise that there is a lot of 
*ebuild* specific stuff there. That has more to do with what an ebuild is 
than what portage does though.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 17:37:35 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| I couldn't find anything in the "default-linux/x86" profile. Could
| you perhaps point something out for me. I realise that there is a lot
| of *ebuild* specific stuff there. That has more to do with what an
| ebuild is than what portage does though.

Look in base/packages:

*>=sys-apps/portage-2.0.51.22
*dev-lang/python

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 17:59, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 17:37:35 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | I couldn't find anything in the "default-linux/x86" profile. Could
> | you perhaps point something out for me. I realise that there is a lot
> | of *ebuild* specific stuff there. That has more to do with what an
> | ebuild is than what portage does though.
>
> Look in base/packages:
>
> *>=sys-apps/portage-2.0.51.22
> *dev-lang/python

I don't see how having these installed is a problem for paludis. While indeed 
these are not needed for another package manager, they do not create problems 
for this package manager.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 17:13:31 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> At this point I don't see that paludis is ready for such thing. In
> any case I think that optimally a package manager does not require
> its own profile.

It doesn't require its own profile. What does require a new profile is
sanely running a paludis-based system without needing to have Portage
and all its dependencies installed.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 17:30, Stephen Bennett wrote:
> On Wed, 17 May 2006 17:13:31 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > At this point I don't see that paludis is ready for such thing. In
> > any case I think that optimally a package manager does not require
> > its own profile.
>
> It doesn't require its own profile. What does require a new profile is
> sanely running a paludis-based system without needing to have Portage
> and all its dependencies installed.

Wouldn't the introduction of the virtual not fix that. This introduction 
could be done independent of anything related to paludis. The 
introduction of such a virtual would also help other package managers 
like pkgcore.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Wed, 17 May 2006 17:39:02 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> Wouldn't the introduction of the virtual not fix that. This
> introduction could be done independent of anything related to
> paludis. The introduction of such a virtual would also help other
> package managers like pkgcore.

That would address some of the immediate concerns, but not any longer
term issues -- the default provider in all profiles would still be
portage, which requires nasty hackery at system install time, for a
start. I'd view changing the system dep to the virtual as a good thing
in itself, but not a substitute for a profile in the tree.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Wednesday 17 May 2006 18:39, Stephen Bennett wrote:
> On Wed, 17 May 2006 17:39:02 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > Wouldn't the introduction of the virtual not fix that. This
> > introduction could be done independent of anything related to
> > paludis. The introduction of such a virtual would also help other
> > package managers like pkgcore.
>
> That would address some of the immediate concerns, but not any longer
> term issues -- the default provider in all profiles would still be
> portage, which requires nasty hackery at system install time, for a
> start. I'd view changing the system dep to the virtual as a good thing
> in itself, but not a substitute for a profile in the tree.

The virtual is by default provided by the installed version. As it is 
necessary to install paludis to use it (even for system install) I don't 
think this is actually a problem. At the point where paludis is in a later 
stage of its development and acceptance, paludis specific profiles can be 
created. As I have argued before, I think that there are various enhancements 
that should be made to paludis before this can happen.

In short, I don't think that paludis is ready to become an official secondary 
package manager.

Personally I would only endorse a secondary package manager if I can go to 
install it on my current system and use it without fear of losing things. 
Even if I decide to discontinue using it. Having to remerge (automatically) 
some packages for it would be acceptable, but I believe that it can be 
avoided.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 13:40:18 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| > Using the normal profiles isn't an option unless they're changed to
| > include virtual/portage in the system set instead of
| > sys-apps/portage. That's the key change we're interested in here --
| > that the system set not pull in portage when paludis is being used
| > instead.
| 
| Is there a problem about both of them being there?

Yes. Portage has a few zillion deps more than Paludis.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

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

On Wed, May 17, 2006 at 12:11:34PM +0100, Stephen Bennett wrote:
> On Wed, 17 May 2006 12:14:37 +0200
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> 
> > Using the normal profiles would also establish paludis as a possible 
> > replacement of portage as primary package manager. Refraining from
> > doing so disqualifies paludis from becoming a replacement for
> > portage. As the only point in adding a secondary package manager is
> > the possible replacement of the current primary package manager, I
> > see no point to make any paludis directed changes to the tree.
> 
> Using the normal profiles isn't an option unless they're changed to
> include virtual/portage in the system set instead of sys-apps/portage.
> That's the key change we're interested in here -- that the system set
> not pull in portage when paludis is being used instead.

Override the virtuals via user side configuration (capabilities 
existant in portage) is one solution to that issue.
~harring

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 12:14:37 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| On Wednesday 17 May 2006 02:42, Stephen Bennett wrote:
| > paludis/packages:
| > -*>=sys-apps/portage-2.0.51.22
| > *sys-apps/paludis
| 
| Is there any reason that portage and paludis can not live together.

Sure they can. That's not what that profile says.

| With the contents of this profile I see no reason whatsoever to
| include it in the tree. Paludis itself could easilly maintain a
| blocker on portage. The rest is so boilerplate that it has no added
| benefit of having paludis use the normal profiles.

Again, that's not what that profile says. You need to read up on how
the packages file works. Basically, lines starting with a - are removed
from the existing set.

| If paludis does not aim at replacing portage

I'm sorry, but the term "Portage replacement" has been banned by the
Gentoo thought police.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Christian Birchinger]

On Wed, May 17, 2006 at 01:42:53AM +0100, Stephen Bennett wrote:
> OK, since several people have asked what is going to be in this profile
> if it gets added, i had in mind something like the following (all
> filenames relative to gentoo-x86/profiles/):
> 
> paludis/deprecated:
> # DO NOT USE THIS PROFILE WITH PORTAGE.
<snip>

Well if people are scared about there could always be a profile
dir with the name "development" "devonly" "broke" "unsupported"
"3rdparty" or whatever (I don't really care). But i guess no
matter how obviously it is, someone will always object.

I'd say everything outside default-linux is fine. If you use
something outside default-linux, some documentation must have
suggested it to you anyway.

With a deprecated (or similar info) the warning sign is big
enough. If someone ignores all warnings and breaks his system
i honestly wouldn't care. I don't even think this is necessary,
but maybe it'll make a few more people accept it.

If we can't even add something this small and trivial for
development, we're doomed and there will be no progress anymore
but only poinless huge discussions.

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

Re: [gentoo-dev] Paludis and Profiles

[Chris Gianelloni]

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

On Wed, 2006-05-17 at 01:42 +0100, Stephen Bennett wrote:
> paludis/packages:
> -*>=sys-apps/portage-2.0.51.22

-*sys-apps/portage would be best

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Paludis and Profiles

[Harald van Dijk]

On Wed, May 17, 2006 at 10:06:54AM -0400, Chris Gianelloni wrote:
> On Wed, 2006-05-17 at 01:42 +0100, Stephen Bennett wrote:
> > paludis/packages:
> > -*>=sys-apps/portage-2.0.51.22
> 
> -*sys-apps/portage would be best

Everything after the - must be *exactly* what is already specified in
base/packages, or it will have no effect.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 10:06:54 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| On Wed, 2006-05-17 at 01:42 +0100, Stephen Bennett wrote:
| > paludis/packages:
| > -*>=sys-apps/portage-2.0.51.22
| 
| -*sys-apps/portage would be best

Unless our code is wrong, that won't work. My understanding of what's
supposed to happen is that -string removes dep atoms equal to that
string. There's no fancy "do these ranges intersect" code, nor can I
think of a way to reasonably define such a thing.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

Given the sheer volume of impassioned response, regardless of any
technical arguments, I'm dropping the top-level profile idea for now.
Several architecture teams have expressed an interest in creating
sub-profiles under their own, however, and I'll be working with them to
get those implemented. Perhaps I'll revisit the top-level idea at a
later date when all the fuss has died down.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Mark Loeser]

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

Stephen Bennett <spb@gentoo.org> said:
> Given the sheer volume of impassioned response, regardless of any
> technical arguments, I'm dropping the top-level profile idea for now.
> Several architecture teams have expressed an interest in creating
> sub-profiles under their own, however, and I'll be working with them to
> get those implemented. Perhaps I'll revisit the top-level idea at a
> later date when all the fuss has died down.

Sub-profiles are included in my statement in the other thread.  Please
hold off on adding or modifying *anything* until the Council has decided
on how we wish to proceed in handling situations like this.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

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

Re: [gentoo-dev] Paludis and Profiles

[Mike Auty]

Forgive me,
	I'm a little new at this and I really don't want to get involved, but
since my inbox has seen nothing but this for the past day or two, I'm
going to ask a few questions I'm interested in the answers to...
	First and foremost is, will adding this to the tree be used for
function creep, whereby the next request to add to/alter the portage
tree is backed up by "Well, the profile change was already added to the
tree"?  I wouldn't want a precedent like this set without the council
reviewing it.
	Secondly, is that what's already being done by asking individual arch
devs to add individual paludis profiles?  Surely paludis would
eventually require all archs to be there, or have I missed something
(which I may have)?  Having already added a file to the profiles
directory, which caused a few posts on here earlier, and then having
asked the question of all the devs so as to avoid a similar incident,
and then received a mixed response, now specific people have been asked
if individually they'll help get paludis in the tree.  Doesn't that seem
a little improper, perhaps?
	Thirdly has anything like this ever happened to Debian or the Sourcery
group?  If so how did they cope with it, and if not, how have they
avoided it?
	As you may have guessed I'm of the, "You can do the same thing with an
overlay, so why must it be in the tree".  I am however willing to wait
and see what the council says, why can't the changes to the tree wait
until then, what is so urgent?  I'm especially intrigued since all this
is simply to no longer require portage as a dependency of system.  Can't
paludis peacefully co-exist with a portage installation for a little
longer, until it's mature?
	Thanks,
	Mike  5:\
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Ryan Phillips]

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

Mike Auty <ikelos@gentoo.org> said:
> Forgive me,
> 	I'm a little new at this and I really don't want to get involved, but
> since my inbox has seen nothing but this for the past day or two, I'm
> going to ask a few questions I'm interested in the answers to...
> 	First and foremost is, will adding this to the tree be used for
> function creep, whereby the next request to add to/alter the portage
> tree is backed up by "Well, the profile change was already added to the
> tree"?  I wouldn't want a precedent like this set without the council
> reviewing it.

I really don't see much of an issue of feature creep.  Gentoo/ALT
already has a profile.  It isn't like there are changes to the actual
ebuilds themselves.

> 	Thirdly has anything like this ever happened to Debian or the Sourcery
> group?  If so how did they cope with it, and if not, how have they
> avoided it?

SMGL has voting and things get done.

> 	As you may have guessed I'm of the, "You can do the same thing with an
> overlay, so why must it be in the tree".  I am however willing to wait
> and see what the council says, why can't the changes to the tree wait
> until then, what is so urgent?  I'm especially intrigued since all this
> is simply to no longer require portage as a dependency of system.  Can't
> paludis peacefully co-exist with a portage installation for a little
> longer, until it's mature?

The question is when is it mature?  I've tried it and Paludis does
work.  There will always be bugs and feature requests.  Its part of
the development process.

Ryan Phillips


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

Re: [gentoo-dev] Paludis and Profiles

[Christian Hartmann]

> > 	First and foremost is, will adding this to the tree be used for
> > function creep, whereby the next request to add to/alter the portage
> > tree is backed up by "Well, the profile change was already added to the
> > tree"?  I wouldn't want a precedent like this set without the council
> > reviewing it.
>
> I really don't see much of an issue of feature creep.  Gentoo/ALT
> already has a profile.  It isn't like there are changes to the actual
> ebuilds themselves.

Actually there are a lot of packages that need portage to work properly. 
Portage has never been added to DEPEND because portage is expected to "be 
just there". With a paludis profile added how are we gonna deal with that?

- Adding $package to the paludis package.mask?
- Creating a $packagemanager virtual and expect every packagemanager to 
provide all the functions offered by portage? (E.g. having wrapperscripts for 
several calls.)
- Make ebuilds that explicit depend on portage depend on portage by adding 
sys-apps/portage to (R)DEPEND?

-- 
Christian Hartmann
http://www.gentoo.org/~ian/

PGP Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865
Key fingerprint = 4544 EC0C BAE4 216F 5981  7F95 2154 E5EE 692A 4865

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Jochen Maes]

First of all, keep up the work with Paludis.
Personally I think having a second package manager is a very good thing.
I do have some questions. Could someone of the Paludis crew please 
answer them?

1) If Paludis has no business in replacing portage on systems (shame, if 
it's better/faster it should) why are we having this discussion.
I understand that you need a profile and with an overlay you need to 
copy the profiles dir (the whole profiles dir) but be serious that's only
So my question would you be able to do tests without changing the 
official tree by copying the profiles dir in an own overlay.

2) If Paludis will be installed on a system to test, and installs 
packages, will portage be aware of that installation, and will it be 
able to remove it (meaning Paludis changes the portage VDB correctly 
when needed). (i've seen you explain that Paludis can read it but not 
that it can write it correctly)

3) If using an own binary format will there be an extracter for it that 
isn't part of Paludis? Why am i asking this? Well i've seen instances 
when an upgrade broke something, and that was a dep of portage. So my 
emerge couldn't revert back. So i just untarred the tarball and 
recompiled it. (might not be the cleanest way, but the only way i found 
in certain situations).

4) Will Paludis ever become a Gentoo Project?


Thank you very much for the hard work!

Jochen



-- 
"Defer no time, delays have dangerous ends"
"Ne humanus crede"

Jochen Maes
Gentoo Linux
Gentoo Belgium
http://sejo.be
http://gentoo.be
http://gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Thu, 18 May 2006 09:19:58 +0200
Jochen Maes <sejo@gentoo.org> wrote:

> 1) If Paludis has no business in replacing portage on systems (shame,
> if it's better/faster it should) why are we having this discussion.
> I understand that you need a profile and with an overlay you need to 
> copy the profiles dir (the whole profiles dir) but be serious that's
> only So my question would you be able to do tests without changing
> the official tree by copying the profiles dir in an own overlay.

We could put profiles in an overlay, but it would require adding
support for inheriting profiles relative to another repository path
rather than relative to the current directory. Doable, but another
place to be incompatible with Portage, so something I'd like to avoid
having to do if possible.

> 2) If Paludis will be installed on a system to test, and installs 
> packages, will portage be aware of that installation, and will it be 
> able to remove it (meaning Paludis changes the portage VDB correctly 
> when needed). (i've seen you explain that Paludis can read it but not 
> that it can write it correctly)

Paludis can read a Portage VDB last time I tried, but a
Paludis-generated VDB will confuse Portage.

> 3) If using an own binary format will there be an extracter for it
> that isn't part of Paludis? 

Yes; it's called tar.

> 4) Will Paludis ever become a Gentoo Project?

Doubtful, barring some rather drastic changes in Gentoo and the way its
projects are handled.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 14:11, Stephen Bennett wrote:
> On Thu, 18 May 2006 09:19:58 +0200
>
> Jochen Maes <sejo@gentoo.org> wrote:
> > 1) If Paludis has no business in replacing portage on systems (shame,
> > if it's better/faster it should) why are we having this discussion.
> > I understand that you need a profile and with an overlay you need to
> > copy the profiles dir (the whole profiles dir) but be serious that's
> > only So my question would you be able to do tests without changing
> > the official tree by copying the profiles dir in an own overlay.
>
> We could put profiles in an overlay, but it would require adding
> support for inheriting profiles relative to another repository path
> rather than relative to the current directory. Doable, but another
> place to be incompatible with Portage, so something I'd like to avoid
> having to do if possible.

Then copy the bloody profile, or temporarilly add some magic in paludis 
that ignores portage and python deps. Not that hard to do. While not so 
beautiful it can easilly be removed at a later stage.
>
> > 2) If Paludis will be installed on a system to test, and installs
> > packages, will portage be aware of that installation, and will it be
> > able to remove it (meaning Paludis changes the portage VDB correctly
> > when needed). (i've seen you explain that Paludis can read it but not
> > that it can write it correctly)
>
> Paludis can read a Portage VDB last time I tried, but a
> Paludis-generated VDB will confuse Portage.

How far does that spread? Is this only for packages merged by paludis, or 
does it spread? And what reasons are there for paludis not to have a vdb 
format that will not confuse portage.

It is very important that package managers coexist with portage. This 
allows testing of that package manager, but also the testing of a 
package / eclass on different package managers. It would be irrealistic 
to require devs to have a different installation just for testing 
packages with paludis/pkgcore.


> > 3) If using an own binary format will there be an extracter for it
> > that isn't part of Paludis?
>
> Yes; it's called tar.
>
> > 4) Will Paludis ever become a Gentoo Project?
>
> Doubtful, barring some rather drastic changes in Gentoo and the way its
> projects are handled.

So you are asking to go towards replacing portage with a package manager 
that is not under gentoo control?

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Thu, 18 May 2006 15:26:06 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> Then copy the bloody profile, or temporarilly add some magic in
> paludis that ignores portage and python deps. Not that hard to do.
> While not so beautiful it can easilly be removed at a later stage.

And if something really does require python?

> How far does that spread? Is this only for packages merged by
> paludis, or does it spread? And what reasons are there for paludis
> not to have a vdb format that will not confuse portage.

A VDB entry created by Paludis can't be read by Portage. A VDB entry
created by Portage can.

> It is very important that package managers coexist with portage. This 
> allows testing of that package manager, but also the testing of a 
> package / eclass on different package managers. It would be
> irrealistic to require devs to have a different installation just for
> testing packages with paludis/pkgcore.

Who's requiring devs to test anything?

> So you are asking to go towards replacing portage with a package
> manager that is not under gentoo control?

Nowhere are we asking for anything to replace Portage as the primary
Gentoo package manager.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 15:58, Stephen Bennett wrote:
> On Thu, 18 May 2006 15:26:06 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > Then copy the bloody profile, or temporarilly add some magic in
> > paludis that ignores portage and python deps. Not that hard to do.
> > While not so beautiful it can easilly be removed at a later stage.
>
> And if something really does require python?
>
> > How far does that spread? Is this only for packages merged by
> > paludis, or does it spread? And what reasons are there for paludis
> > not to have a vdb format that will not confuse portage.
>
> A VDB entry created by Paludis can't be read by Portage. A VDB entry
> created by Portage can.

This is not a reason. It is just repeating what I just said. Which 
features does paludis have for its VDB format. And (per feature) why 
can't this be done in a compatible way.

>
> > It is very important that package managers coexist with portage. This
> > allows testing of that package manager, but also the testing of a
> > package / eclass on different package managers. It would be
> > irrealistic to require devs to have a different installation just for
> > testing packages with paludis/pkgcore.
>
> Who's requiring devs to test anything?

If I am to be a responsible package manager I have to test my package 
before I commit it into the repository. At a point where paludis has a 
status different from totally unsupported, this includes testing it with 
paludis next to testing it with portage.

Besides this, to make an informed decision about granting paludis some 
more than totally unsupported status it is necessary to first test 
paludis. I, and I think many other devs with me, am reluctant to create a 
whole new tree to test out paludis. I also do not want to copy my whole 
tree to test it.

>
> > So you are asking to go towards replacing portage with a package
> > manager that is not under gentoo control?
>
> Nowhere are we asking for anything to replace Portage as the primary
> Gentoo package manager.

What do you want then? Paludis does not aim to be compatible with portage, 
so this disqualifies paludis as a secondary package manager. Two primary 
package managers is nonsensical. You ask for support in the tree for 
paludis, meaning that you don't want to be unsupported third party 
either. This leaves that you aim at paludis possibly becomming a portage 
replacement.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Thu, 18 May 2006 16:50:59 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> This is not a reason. It is just repeating what I just said. Which 
> features does paludis have for its VDB format. And (per feature) why 
> can't this be done in a compatible way.

We store more information than Portage in VDB, to remove the reliance
that current Portage has on certain parts of the tree being immutable
and in order to support multiple repositories properly (there is no
longer a single place to look for, say, eclass data at uninstall time).
We also construct VDB entries for old-style virtuals, which will
confuse Portage.

> What do you want then? Paludis does not aim to be compatible with
> portage, so this disqualifies paludis as a secondary package manager.

It aims to be compatible with the tree. As far as I know, it succeeds
as things currently stand.

> Two primary package managers is nonsensical. You ask for support in
> the tree for paludis, meaning that you don't want to be unsupported
> third party either. This leaves that you aim at paludis possibly
> becomming a portage replacement.

At present I ask not for support, but for a minor addition for
convenience purposes.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 17:44, Stephen Bennett wrote:
> On Thu, 18 May 2006 16:50:59 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > This is not a reason. It is just repeating what I just said. Which
> > features does paludis have for its VDB format. And (per feature) why
> > can't this be done in a compatible way.
>
> We store more information than Portage in VDB, to remove the reliance
> that current Portage has on certain parts of the tree being immutable
> and in order to support multiple repositories properly (there is no
> longer a single place to look for, say, eclass data at uninstall time).

Is there any reason that this extra information can not be added in such a way 
that portage will just silently ignore it. Which changes to portage would be 
required to make it ignore it (but silently remove it when a package is 
removed).

> We also construct VDB entries for old-style virtuals, which will
> confuse Portage.

Is there no way in which portage could be made to ignore this. Or to not 
create these entries (as portage can work without them). Being compatible 
with portage can mean extending portage such that compatibility is easier.

> > Two primary package managers is nonsensical. You ask for support in
> > the tree for paludis, meaning that you don't want to be unsupported
> > third party either. This leaves that you aim at paludis possibly
> > becomming a portage replacement.
>
> At present I ask not for support, but for a minor addition for
> convenience purposes.

One that has more disadvantages than advantages as already pointed out.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 19:55:34 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| Is there any reason that this extra information can not be added in
| such a way that portage will just silently ignore it.

Portage's handling of unrecognised data is not sufficiently clever to
allow this to be done in any reasonable manner.

| > We also construct VDB entries for old-style virtuals, which will
| > confuse Portage.
| 
| Is there no way in which portage could be made to ignore this.

There are ways, but they all involve adding in really nasty hacks that
will just keep on getting messier and messier in the future.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Grant Goodyear]

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

Paul de Vrieze wrote:
>> At present I ask not for support, but for a minor addition for
>> convenience purposes.
> 
> One that has more disadvantages than advantages as already pointed out.

Many of your comments have been quite valuable, but I've noticed that
your recent posts fail to distinguish between facts and your opinion.
This last statement falls into that latter category, of course, since
the relative weighting of advantages and disadvantages has been pretty
subjective so far.

Incidentally, in reading this thread it seems to me that a tendency to
offer opinions (or predictions) as though they were facts has been a
common theme.  Please try to separate the two, whenever possible.

Thanks,
g2boojum


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

Re: [gentoo-dev] Paludis and Profiles

[Grant Goodyear]

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

Grant Goodyear wrote:
> Incidentally, in reading this thread it seems to me that a tendency to
> offer opinions (or predictions) as though they were facts has been a
> common theme.  Please try to separate the two, whenever possible.

Just to clarify, I was not limiting that comment to pauldv.

-g2boojum-


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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 15:26:06 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| Then copy the bloody profile, or temporarilly add some magic in
| paludis that ignores portage and python deps. Not that hard to do.
| While not so beautiful it can easilly be removed at a later stage.

That removes valid dependencies.

| How far does that spread? Is this only for packages merged by
| paludis, or does it spread? And what reasons are there for paludis
| not to have a vdb format that will not confuse portage.

Anything merged by Paludis may have a VDB entry that will confuse
Portage. This is necessary for two reasons. Firstly, we have some
features that Portage doesn't. Secondly, the VDB entries generated by
Portage under certain circumstances (symlink/dir merge mismatches) are
incomplete and incorrect, and Portage's unmerge code will falsely
remove and falsely leave behind garbage when this happens, and we see
no reason to emulate this bug.

| It is very important that package managers coexist with portage. This 
| allows testing of that package manager, but also the testing of a 
| package / eclass on different package managers. It would be
| irrealistic to require devs to have a different installation just for
| testing packages with paludis/pkgcore.

Can you install Portage 2.0 and Portage 2.1 in parallel?

| > > 4) Will Paludis ever become a Gentoo Project?
| >
| > Doubtful, barring some rather drastic changes in Gentoo and the way
| > its projects are handled.
| 
| So you are asking to go towards replacing portage with a package
| manager that is not under gentoo control?

What about Portage is under Gentoo control? Were Portage under Gentoo
control, it would have the features that Gentoo developers require by
now. Like, say, :slot deps. Similarly, Gentoo has no problem with bash,
despite it not being a Gentoo project...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 18:26, Ciaran McCreesh wrote:
> On Thu, 18 May 2006 15:26:06 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | Then copy the bloody profile, or temporarilly add some magic in
> | paludis that ignores portage and python deps. Not that hard to do.
> | While not so beautiful it can easilly be removed at a later stage.
>
> That removes valid dependencies.

Just remove it from the paludis system set. Is it that hard?

> | How far does that spread? Is this only for packages merged by
> | paludis, or does it spread? And what reasons are there for paludis
> | not to have a vdb format that will not confuse portage.
>
> Anything merged by Paludis may have a VDB entry that will confuse
> Portage. This is necessary for two reasons. Firstly, we have some
> features that Portage doesn't. Secondly, the VDB entries generated by
> Portage under certain circumstances (symlink/dir merge mismatches) are
> incomplete and incorrect, and Portage's unmerge code will falsely
> remove and falsely leave behind garbage when this happens, and we see
> no reason to emulate this bug.

Then do it correct in a way that portage can still live with it. Otherwise 
write a portage patch so that it can live with it.

> Can you install Portage 2.0 and Portage 2.1 in parallel?

These are versions of the same official package manager. A different 
situation.

>
> | > > 4) Will Paludis ever become a Gentoo Project?
> | >
> | > Doubtful, barring some rather drastic changes in Gentoo and the way
> | > its projects are handled.
> |
> | So you are asking to go towards replacing portage with a package
> | manager that is not under gentoo control?
>
> What about Portage is under Gentoo control? Were Portage under Gentoo
> control, it would have the features that Gentoo developers require by
> now. Like, say, :slot deps. Similarly, Gentoo has no problem with bash,
> despite it not being a Gentoo project...

Bash is not the gentoo package manager. If the council decided to tomorrow, it 
could revert portage releases, freeze portage releases, lock access to 
portage etc. It is under gentoo control.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 09:19:58 +0200 Jochen Maes <sejo@gentoo.org> wrote:
| 1) If Paludis has no business in replacing portage on systems (shame,
| if it's better/faster it should) why are we having this discussion.

It's a goal towards which we're working. Just as we expect that, for
example, gcc 4 will someday replace gcc 3 on some archs.

| I understand that you need a profile and with an overlay you need to 
| copy the profiles dir (the whole profiles dir) but be serious that's
| only So my question would you be able to do tests without changing
| the official tree by copying the profiles dir in an own overlay.

That's how things are done at present.

| 2) If Paludis will be installed on a system to test, and installs 
| packages, will portage be aware of that installation, and will it be 
| able to remove it (meaning Paludis changes the portage VDB correctly 
| when needed). (i've seen you explain that Paludis can read it but not 
| that it can write it correctly)

It's not that Paludis doesn't write it correctly. It's that Paludis
writes some extra information that Portage can't handle.

| 3) If using an own binary format will there be an extracter for it
| that isn't part of Paludis? Why am i asking this? Well i've seen
| instances when an upgrade broke something, and that was a dep of
| portage. So my emerge couldn't revert back. So i just untarred the
| tarball and recompiled it. (might not be the cleanest way, but the
| only way i found in certain situations).

tar.

| 4) Will Paludis ever become a Gentoo Project?

Pretty unlikely, past events considered. Personally I kind of like
having commit access to my own code...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Grant Goodyear]

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

Ciaran McCreesh wrote:
> | 4) Will Paludis ever become a Gentoo Project?
> 
> Pretty unlikely, past events considered. Personally I kind of like
> having commit access to my own code...

I thought we (Gentoo) already had SVN repositories with non-Gentoo-dev
committers?  I'm pretty sure that was one of the main goals behind
stuart's overlay.gentoo.org proposal.

-g2boojum-


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

Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 11:44:40 -0500 Grant Goodyear <g2boojum@gentoo.org>
wrote:
| Ciaran McCreesh wrote:
| > | 4) Will Paludis ever become a Gentoo Project?
| >
| > Pretty unlikely, past events considered. Personally I kind of like
| > having commit access to my own code...
| 
| I thought we (Gentoo) already had SVN repositories with non-Gentoo-dev
| committers?  I'm pretty sure that was one of the main goals behind
| stuart's overlay.gentoo.org proposal.

Yes, but I'm a security risk, remember? Thus why gentoo-syntax is now
more or less dead...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Marius Mauch]

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

On Thu, 18 May 2006 11:44:40 -0500
Grant Goodyear <g2boojum@gentoo.org> wrote:

> Ciaran McCreesh wrote:
> > | 4) Will Paludis ever become a Gentoo Project?
> > 
> > Pretty unlikely, past events considered. Personally I kind of like
> > having commit access to my own code...
> 
> I thought we (Gentoo) already had SVN repositories with non-Gentoo-dev
> committers?  I'm pretty sure that was one of the main goals behind
> stuart's overlay.gentoo.org proposal.

getting OT now (but what in this thread is really on topic?), but
overlays.g.o shouldn't be for general software hosting a la
sourceforge, just for extensions to the tree (so a profile would fit in
there, but not the paludis code itself).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] Paludis and Profiles

[Jochen Maes]

** Dumb mode **  forgot to paste the exact size of the profiles dir in 
my previous mail... woops :-)

First of all, keep up the work with Paludis.
Personally I think having a second package manager is a very good thing.
I do have some questions. Could someone of the Paludis crew please 
answer them?

1) If Paludis has no business in replacing portage on systems (shame, if 
it's better/faster it should) why are we having this discussion.
I understand that you need a profile and with an overlay you need to 
copy the profiles dir (the whole profiles dir) but be serious that's 
only 7.4 M
So my question would you be able to do tests without changing the 
official tree by copying the profiles dir in an own overlay.

2) If Paludis will be installed on a system to test, and installs 
packages, will portage be aware of that installation, and will it be 
able to remove it (meaning Paludis changes the portage VDB correctly 
when needed). (i've seen you explain that Paludis can read it but not 
that it can write it correctly)

3) If using an own binary format will there be an extracter for it that 
isn't part of Paludis? Why am i asking this? Well i've seen instances 
when an upgrade broke something, and that was a dep of portage. So my 
emerge couldn't revert back. So i just untarred the tarball and 
recompiled it. (might not be the cleanest way, but the only way i found 
in certain situations).

4) Will Paludis ever become a Gentoo Project?


Thank you very much for the hard work!

Jochen

-- 
"Defer no time, delays have dangerous ends"
"Ne humanus crede"

Jochen Maes
Gentoo Linux
Gentoo Belgium
http://sejo.be
http://gentoo.be
http://gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 01:23, Ryan Phillips wrote:
> Mike Auty <ikelos@gentoo.org> said:
> > Forgive me,
> > 	I'm a little new at this and I really don't want to get involved,
> > but since my inbox has seen nothing but this for the past day or two,
> > I'm going to ask a few questions I'm interested in the answers to...
> > First and foremost is, will adding this to the tree be used for
> > function creep, whereby the next request to add to/alter the portage
> > tree is backed up by "Well, the profile change was already added to
> > the tree"?  I wouldn't want a precedent like this set without the
> > council reviewing it.
>
> I really don't see much of an issue of feature creep.  Gentoo/ALT
> already has a profile.  It isn't like there are changes to the actual
> ebuilds themselves.

This is my main point. I believe that adding the profile now will lead to 
function creep. Given the stated direction of paludis to be INCOMPATTIBLE 
with portage, this will eventually lead to either replacing portage or 
forcing portage into directions that gentoo does not wish to go.

>
> > 	Thirdly has anything like this ever happened to Debian or the
> > Sourcery group?  If so how did they cope with it, and if not, how
> > have they avoided it?
>
> SMGL has voting and things get done.

Wrong answer. It does not answer the question. SOURCERY!=SMGL

>
> > 	As you may have guessed I'm of the, "You can do the same thing with
> > an overlay, so why must it be in the tree".  I am however willing to
> > wait and see what the council says, why can't the changes to the tree
> > wait until then, what is so urgent?  I'm especially intrigued since
> > all this is simply to no longer require portage as a dependency of
> > system.  Can't paludis peacefully co-exist with a portage
> > installation for a little longer, until it's mature?
>
> The question is when is it mature?  I've tried it and Paludis does
> work.  There will always be bugs and feature requests.  Its part of
> the development process.

It is mature when I can install it in my gentoo system. Try it out on some 
ebuilds. Check whether my ebuild is compatible with paludis and portage 
(in the same system), and not break my system horibly. If only 
undocumented tricks will allow this this means that paludis is not yet 
mature.

Yes, any package manager that claims to work with ebuilds is only mature 
when it cooperates in a portage environment. This means that either you 
cooperate with portage, or you get the portage developers to introduce 
the things you need into a stable portage.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 00:26, Stephen Bennett wrote:
> Given the sheer volume of impassioned response, regardless of any
> technical arguments, I'm dropping the top-level profile idea for now.
> Several architecture teams have expressed an interest in creating
> sub-profiles under their own, however, and I'll be working with them to
> get those implemented. Perhaps I'll revisit the top-level idea at a
> later date when all the fuss has died down.

I seriously disagree with this action. Such profiles have the same 
problems as a toplevel profile, and as such are just as problematic as a 
toplevel paludis profile.

Since the profile does not actually add anything except making portage a 
virtual (which is independent of paludis, and a good idea in any case), 
there is also no use for doing so.

If you really really need to have a profile, it might be discussable to 
have no-portage profiles, that do not include portage or python in 
system. These however must still be portage compatible, and independent 
of a package manager.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Thu, 18 May 2006 12:18:41 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> If you really really need to have a profile, it might be discussable
> to have no-portage profiles, that do not include portage or python in 
> system. These however must still be portage compatible, and
> independent of a package manager.

In the arch-specific subprofile case, we'd likely be dropping any
features that would cause Portage to choke, and simply changing the
system set and virtuals around.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 14:14, Stephen Bennett wrote:
> On Thu, 18 May 2006 12:18:41 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > If you really really need to have a profile, it might be discussable
> > to have no-portage profiles, that do not include portage or python in
> > system. These however must still be portage compatible, and
> > independent of a package manager.
>
> In the arch-specific subprofile case, we'd likely be dropping any
> features that would cause Portage to choke, and simply changing the
> system set and virtuals around.

I know you would do that. My problem is not with how it is done. But what 
is done. The problem is not about portage choking. The problem is that at 
this point there is no reason to make paludis specific changes to the 
tree.

Making package manager specific changes to the tree/profiles is even more 
a dead end. This would mean that package managers are bound to a profile 
(making it impossible to use the package manager properly). It would also 
mean that every package manager would have its own profiles. A needless 
duplication that gets you nowhere.

And these are only the technical points.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Thu, 18 May 2006 15:31:29 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> I know you would do that. My problem is not with how it is done. But
> what is done. The problem is not about portage choking. The problem
> is that at this point there is no reason to make paludis specific
> changes to the tree.

Changes are made to profiles all the time for the benefit of a package
in the tree. How is this different?

> Making package manager specific changes to the tree/profiles is even
> more a dead end. This would mean that package managers are bound to a
> profile (making it impossible to use the package manager properly).

It would not be bound to a profile in any way. It can read and use any
profile that Portage can. The new profile(s) would be purely for the
convenience of those who want to use it and don't want Portage
installed.

> It would also mean that every package manager would have its own
> profiles. A needless duplication that gets you nowhere.

And how is this any different from having seperate subprofiles for NPTL
or no-NPTL, for 2.4 or 2.6 kernels, or different compiler versions?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze]

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

On Thursday 18 May 2006 16:02, Stephen Bennett wrote:
> On Thu, 18 May 2006 15:31:29 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > I know you would do that. My problem is not with how it is done. But
> > what is done. The problem is not about portage choking. The problem
> > is that at this point there is no reason to make paludis specific
> > changes to the tree.
>
> Changes are made to profiles all the time for the benefit of a package
> in the tree. How is this different?

Paludis is not just a package, it is an alternative package manager. The 
proposed changes are also not just the setting of a default for a 
useflag. What you are requesting is adding a different version of gentoo.

A package manager should not mean a different version at all. Whether I 
install subversion with portage or with paludis should not make any 
difference in the installed result.

> It would not be bound to a profile in any way. It can read and use any
> profile that Portage can. The new profile(s) would be purely for the
> convenience of those who want to use it and don't want Portage
> installed.

I already stated that I would find a no-portage profile discussable. This 
profile would then mean that portage, pkg-core, and paludis would be able 
to handle it. 

I am not sure though whether having a portage virtual would not be enough. 
As portage depends on python, it would be worthwhile to research whether 
removing python from the default package list works. In that case it is 
possible to remove the explicit portage dependency from the tree.

>
> > It would also mean that every package manager would have its own
> > profiles. A needless duplication that gets you nowhere.
>
> And how is this any different from having seperate subprofiles for NPTL
> or no-NPTL, for 2.4 or 2.6 kernels, or different compiler versions?

Those profiles are not tied to the package manager. A package manager does 
not change anything to the installed system (except its own metadata). 
All these other profiles do.

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Paludis and Profiles

[Stephen Bennett]

On Thu, 18 May 2006 16:30:48 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:

> Paludis is not just a package, it is an alternative package manager.
> The proposed changes are also not just the setting of a default for a 
> useflag.

So? It's a package in the tree, and I'd like a new profile to make best
use of it. Compare with the commercial/mysql profile if you like. The
fact that its main purpose is to install software is irrelevant.

> What you are requesting is adding a different version of
> gentoo.

Right, in the same way that the Alpha or hardened profiles are a
different version of gentoo.

> I already stated that I would find a no-portage profile discussable.
> This profile would then mean that portage, pkg-core, and paludis
> would be able to handle it. 

This I would see as a viable alternative in the short term. It should
probably be moved into a different thread though, due to the sheer
volume of noise in this one.

> I am not sure though whether having a portage virtual would not be
> enough. As portage depends on python, it would be worthwhile to
> research whether removing python from the default package list works.
> In that case it is possible to remove the explicit portage dependency
> from the tree.

Again, a step in the right direction, but should probably be in its own
thread by now.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Roy Bamford]

On 2006.05.16 16:15, Stephen Bennett wrote:
> If noone has any strong reasonable objections, I'd like to add a
> Paludis profile to the tree. This would use Paludis as the default
> provider for virtual/portage (which is a less than ideal name, but
> that
> is another discussion entirely), and provide ebuild devs with a place
> where they can try out some of our profile enhancements should they
> want to. It is worth noting on the last point that most of these are
> long-standing Portage feature requests, at least some of which are
> planned for inclusion in Portage at some point in the future. This
> would allow devs access to them earlier, as a sort of testbed.
> 
> The next question is where to put it. The options as I see them are
> under default-linux/x86/ or in a top-level paludis/ a la hardened,
> selinux, embedded, and the like. The latter is easier to exclude for
> those worried about tree size, though the impact there should be
> minimal. Neither way produces significantly more duplication, since we
> can make use of multiple profile inheritance. If anyone has any
> preference or other input, I'd like to hear it.
> 
> That's my proposal. The benefits I like to think are obvious. The
> drawbacks are, as far as I can see, in tree size, which should be
> minimal. Those concerned about local tree size can exclude it, and for
> size on the mirrors it's trivial compared to the rest of the tree.
> 
> Comments?
> --
> gentoo-dev@gentoo.org mailing list

Hi all,

Being new to this list and having read every post since just before  
this discussion started, I feel its time for a generic summing up.  
There are a number of interesting questions arising from the thread  
along the lines of

1) Should the Gentoo tree support alternative package managers at all?

2) Should the tree be changed to enable experimental support to be  
added for alternative package managers?

3) Do alternative package managers have to be (at least) backwards  
compatible with Portage?

4) Should Portage be replaced by one (or more) of the alternatives?

I'm deliberately avoiding the use of any names because Portage is the  
incumbent package manager and the questions have only been raised by  
one alternative package manager *so far*.

Question 1) and 2) can be answered in the same breath. If its decided  
that alternative package managers will be supported then any required  
changes to make that possible are inferred, if indeed, its not actually  
possible at the moment. 1) is really a political/policy  question, not  
a software engineering question, so should be determined by the council.

3) The answer has to be, as a minimum, alternate package managers need  
to be able to build on what Portage has already installed. That is, be  
backwards compatible. There is no need for users to have an 'undo'  
feature short of a reinstall. Experimental packages are just that, if  
you really might not be able to take the consequences, don't  
experiment. That's no different than for any other package now.

4) This does not even arise until satisfactory answers have been  
obtained to 1) and 2) and any potential Portage replacement has  
undergone a period of testing. However, there has to be a a way of  
migrating the user base to any new package manager should Portage  
become depreciated. Again, just like any other package.

When alternate package manager(s) are proved to safely (no worse than  
portage) do everything from install to maintenance, there may be an  
interim stage where users can choose to install using package manager  
'A' or package manager 'B', knowing that they cannot switch without a  
reinstall.

There is no package in the tree that is sacrosanct - not even Portage.
Gentoo must evolve (all of it) or die. The process is all self evident,  
its the same process that's followed for every other package in the  
tree.

You probably don't want my views but here they are anyway.
1) Yes - packages managers are just packages, like every other package.

2) Yes - in a generic way. No special concessions to any particular  
package manager. I know its not like that at the moment because Portage  
defined Gentoo. Looking into the distant future, we can expect Package  
Managers to be replaced like other packages.

3) I'm ambivalent - I'm a user not a dev.

4) Only time will tell.

Regards,

Roy Bamford
(NeddySeagoon)

-- 
gentoo-dev@gentoo.org mailing list