Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>]

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

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

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

What's your point?

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

And hey, we do provide a consistent environment.

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

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

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

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

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

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

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

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

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

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

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

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

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

Elsewhere in the thread.

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

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

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


-- 
gentoo-dev@gentoo.org mailing list