[gentoo-dev] Paludis and Profiles
Stephen Bennett
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?
--
gento...@gentoo.org mailing list
Brian Harring
> 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
Thomas Cort
Stephen Bennett <s...@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 <tc...@gentoo.org>
(oo)____ |SAVE LARRY| | Gentoo Linux Developer
(__) )\ +----------+ | alpha, amd64, sound
||--|| * | | http://dev.gentoo.org/~tcort
Ciaran McCreesh
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
--
gento...@gentoo.org mailing list
Mark Loeser
> 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
Diego 'Flameeyes' Pettenò
> 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.
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
Stephen Bennett
> 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*
--
gento...@gentoo.org mailing list
Alec Warner
> On Tue, 16 May 2006 09:16:18 -0700 Brian Harring <ferr...@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
--
gento...@gentoo.org mailing list
Christian Hartmann
> 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
--
gento...@gentoo.org mailing list
Ciaran McCreesh
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
<flam...@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.
Stephen Bennett
> 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.
--
gento...@gentoo.org mailing list
Stephen Bennett
> 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.
--
gento...@gentoo.org mailing list
Stephen Bennett
> 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.
--
gento...@gentoo.org mailing list
Diego 'Flameeyes' Pettenò
> That's rather funny, when one considers the whole BSD profile structure
> and the zillions of ebuild changes that've been made for BSD.
directly handled by me (the BSD team), not handled down to maintainers at
all.
Stephen Bennett
> I would prefer to see the profile you are commiting then; do you have a
> link?
I haven't written it yet.
--
gento...@gentoo.org mailing list
Ciaran McCreesh
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.
Brian Harring
> 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
Fernando J. Pereda
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
Brian Harring
> On Tue, 16 May 2006 09:16:18 -0700 Brian Harring <ferr...@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
Mike Frysinger
> > 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
Grant Goodyear
> 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
g2bo...@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76
Ciaran McCreesh
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.
Grant Goodyear
> | 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)?
Gustavo Zacarias
> 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
--
gento...@gentoo.org mailing list
Stephen Bennett
> 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.
--
gento...@gentoo.org mailing list
Stephen Bennett
> 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.
--
gento...@gentoo.org mailing list
Daniel Drake
> If noone has any strong reasonable objections, I'd like to add a
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
--
gento...@gentoo.org mailing list
Danny van Dyk
[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
pal...@berlios.de. We are really interested to know which packages
don't work.
Danny
--
Danny van Dyk <kuge...@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gento...@gentoo.org mailing list
Diego 'Flameeyes' Pettenò
> They're rather minimal, and still an order of magnitude larger than what
> I'm proposing here.
experimenting with it.
Robin H. Johnson
> Comments?
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 : rob...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Wernfried Haas
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
Luis Francisco Araujo
> 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.
>
>
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).
--
gento...@gentoo.org mailing list
Luis Medinas
> 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.
Gentoo is somemething just not because of us but because of Portage too.
Like Danny wrote i think we(amd64) can handle one more profile and yes i
agree with paludis implementation on our tree too. I don't expect
paludis will replace portage but isn't Gentoo about choice ?
So good luck with paludis development.
--
gento...@gentoo.org mailing list
Diego 'Flameeyes' Pettenò
> Sorry if i am confusing things here, but isn't this just _yet_ another
> profile that
> the user can choose to use?
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".
Ciaran McCreesh
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
<flam...@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...)
Brian Harring
> On Tue, 16 May 2006 10:33:56 -0700 Brian Harring <ferr...@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
Ciaran McCreesh
| 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.
Jan Kundrát
> 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
Diego 'Flameeyes' Pettenò
> Somehow I don't think
> we're the ones spreading the FUD here.
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.
Daniel Drake
> 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...
Chris Gianelloni
(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
Ciaran McCreesh
<flam...@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
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.
Stephen Bennett
> 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.
--
gento...@gentoo.org mailing list
Chris Gianelloni
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.
Diego 'Flameeyes' Pettenò
> Perhaps you should've read Halcy0n's post:
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?
Luis Francisco Araujo
> 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.
--
gento...@gentoo.org mailing list
Ciaran McCreesh
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.
Diego 'Flameeyes' Pettenò
> It will be supported by me, and the other devs involved with Paludis.
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.
Simon Stelling
> 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
--
gento...@gentoo.org mailing list
Ciaran McCreesh
<flam...@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".
Jeroen Roovers
On Tue, 16 May 2006 21:05:52 +0200
Danny van Dyk <kuge...@gentoo.org> wrote:
> 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 pal...@berlios.de. We are really interested to
> know which packages don't work.
This should not be a side note IMHO. If that profile is in the tree,
who in Gentoo will support it? Does the Gentoo Project not support the
entire tree all of a sudden? In other words:
1) Is bugsy ready for this, with appropriate categories in place?
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?
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?
In my opinion, when these support requirements (and then some) are met,
i.e. when it is obvious who (which team of Gentoo devs) support the
Paludis profile (within the existing communications infrastructure), I
and every other dev will be ready for it.
Kind regards,
JeR
--
gento...@gentoo.org mailing list
Stephen Bennett
"Diego 'Flameeyes' Pettenò" <flam...@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
s...@gentoo.org for now. Since profile is among the information we
routinely ask for on bug reports, identifying them shouldn't be a
Marius Mauch
Stephen Bennett <s...@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.
Stephen Bennett
Jeroen Roovers <j...@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/
--
gento...@gentoo.org mailing list
Brian Harring
> On Tue, 16 May 2006 12:55:11 -0700 Brian Harring <ferr...@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?
Don't troll- portage interacts with the ebuild in predefined ways
(hooks), certain vars are expected by ebuilds to be available. Start
with man 5 ebuild if you'd like. Variable renaming is stupid, but
does break stuff. Dropping locals will result in the same thing.
> | > 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.
The problem is that portage (warts and all) trumps paludis when it
comes to defining what ebuilds can/cannot do- changing the ebuild
support results in one thing, and one thing only- breaking the
support for ebuilds.
Users are the ones who will see it also. You may not think it matters
much now, but when you add per phase stepping support (what
/usr/lib/portage/bin/ebuild provides), you'll start seeing the issues
more and more.
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...
> | 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.
> | > *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.
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.
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.
> | 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
2) EAPI as a function is no different then EAPI as a var, just
massively slower since you have to shell out more.
> | > 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.
> | 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.
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.
Portage gets it wrong by forcing all repos to be overlays of PORTDIR.
Going to the other extreme is no better- it's one turd for another.
> | > 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.
Stating it "won't be a silent failure" does not make it so- line 1023
of portage.py directly contradicts that.
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...
> | 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? :)
Thing is, folks don't even know what the hell you're planning on
sticking in there. Profiles are touchy as all hell, a blank check
without some details is tricky in light of that.
> | > 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.
Saving and using of locals has existed in portage long before you ever
even became a dev (same for me)- labeling it a bug is a bit daft in
that case.
> | 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 and I'll go back to doing real work. Changes to ebuild
support shouldn't be tested in the tree.
~harring
Danny van Dyk
> On Tue, 16 May 2006 16:15:49 +0100
>
> Stephen Bennett <s...@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?
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.
Danny
--
Danny van Dyk <kuge...@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gento...@gentoo.org mailing list
Brian Harring
> 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
Carsten Lohrke
> > 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
Stephen Bennett
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.
--
gento...@gentoo.org mailing list
Mike Frysinger
> 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
Christian Hartmann
> 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
--
gento...@gentoo.org mailing list
Christian Hartmann
> 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
> 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.
Matthijs van der Vleuten
> > 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.)
--
gento...@gentoo.org mailing list
Wernfried Haas
> 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
Paul de Vrieze
> On Tue, 16 May 2006 22:59:59 +0200
>
> "Diego 'Flameeyes' Pettenò" <flam...@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: pau...@gentoo.org
Homepage: http://www.devrieze.net
Roy Marples
> 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 <uber...@gentoo.org>
Gentoo/Linux Developer (baselayout, networking)
--
gento...@gentoo.org mailing list
Paul de Vrieze
>
> 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 de Vrieze
>
> 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.
Simon Stelling
> 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).
Stephen Bennett
Paul de Vrieze <pau...@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.
--
gento...@gentoo.org mailing list
Wernfried Haas
> 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.
Christian Birchinger
> 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/):
>
> # DO NOT USE THIS PROFILE WITH PORTAGE.
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
--
gento...@gentoo.org mailing list
Paul de Vrieze
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.
Stephen Bennett
Paul de Vrieze <pau...@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.
--
gento...@gentoo.org mailing list
Ciaran McCreesh
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
--
gento...@gentoo.org mailing list
Chris Gianelloni
> On Tue, 16 May 2006 22:59:59 +0200
> "Diego 'Flameeyes' Pettenò" <flam...@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
Ciaran McCreesh
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.
Chris Gianelloni
> > 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.
Ciaran McCreesh
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
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
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.
Stephen Bennett
Chris Gianelloni <wolf...@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.
--
gento...@gentoo.org mailing list
Ciaran McCreesh
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.
Carsten Lohrke
> On Wed, 17 May 2006 01:58:02 +0200 Carsten Lohrke <ca...@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
Patrick McLean
> 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).
--
gento...@gentoo.org mailing list
George Prowse
Ciaran McCreesh
<wolf...@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...
Diego 'Flameeyes' Pettenò
> Deprecated profiles are considered unsupported, as are most of the
> gentoo-alt profiles
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
Stephen Bennett
"George Prowse" <coke...@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.
--
gento...@gentoo.org mailing list
Chris Gianelloni
> On 5/17/06, Christian Hartmann <i...@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.
Harald van Dijk
> 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.
--
gento...@gentoo.org mailing list
Chris Gianelloni
> - 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.
Ciaran McCreesh
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.