From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Fg5rn-0003Jx-9T for garchives@archives.gentoo.org; Tue, 16 May 2006 20:10:03 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4GK6rfY021993; Tue, 16 May 2006 20:06:53 GMT Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.154]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4GJtRDN021204 for ; Tue, 16 May 2006 19:55:28 GMT Received: from nightcrawler (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (rwcrmhc14) with SMTP id <20060516195523m1400kjedhe>; Tue, 16 May 2006 19:55:23 +0000 Date: Tue, 16 May 2006 12:55:11 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Paludis and Profiles Message-ID: <20060516195511.GA29839@nightcrawler> References: <20060516161549.442b4d8a@localhost> <20060516161618.GB28745@nightcrawler> <20060516174742.66cf8f04@snowdrop.home> <20060516173356.GC28745@nightcrawler> <20060516190705.0f865431@snowdrop.home> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20060516190705.0f865431@snowdrop.home> User-Agent: Mutt/1.5.11 X-Archives-Salt: c4b539c3-42e4-4f7c-b91d-96e5caa4f8bb X-Archives-Hash: 07a76c9a56cd75d3ca2a9a503477594a --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 16, 2006 at 07:07:05PM +0100, Ciaran McCreesh wrote: > On Tue, 16 May 2006 10:33:56 -0700 Brian Harring > wrote: > | > What eapi=3D0 standard? We emulate Portage internals where it's found > | > to be necessary, and don't otherwise. > |=20 > | eapi=3D0 is what 2.1/2.05x supports. >=20 > 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. =2E..which is why the ebuild env for portage is extremely carefully=20 maintained- mistakes may occur, but willy nilly changes don't. =20 Regardless, at least for gentoo it still however *is* the standard=20 for ebuilds, breaking the 'standard' out of portage is fine, changing=20 intrinsic parts of the standard isn't. > | Features are fine, but for gentoo backwards compatibility *is* a=20 > | concern, as such dropping the bits that you dislike (but existing=20 > | ebuilds rely on) is a no go. >=20 > 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=20 handling via intentionally dropping all local vars defined per phase=20 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. >=20 > *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=20 you stated above, the data (ebuilds) handling is what matters. =20 Stating that the bash concerns are trivial while the C++ side can be=20 interesting is ignoring the point, the bash bits must match- I don't=20 care if it's C++ or python or haskell for the high level, the ebuild=20 env support must *not* induce any intentional changes that break=20 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-=20 it's actually a decent example of how to do the changeover- that was=20 also a permenant change, not a "paludis is an alternative and we want=20 to stick it in the tree". > | Feature introduction is done via introducing support, then sitting on= =20 > | it for ~6 months to ensure folks don't get bit by it- notable=20 > | exception was virtuals/* metapkg, although the buttload of bugs from=20 > | it is a demonstration of *why* this route must be taken. >=20 > 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=20 expose users to sharp/pointy things without a good reason". > | This is also why eapi came about- faster introduction of > | compatibility breaking changes. >=20 > 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=20 comments on it haven't really progressed beyond "y'all did it badly",=20 without naming a solution that works. EAPI has it's faults, but it *does* version the ebuild format=20 (regardless of the tree format) to move forward, which was it's=20 intention. Versioning the tree format is a related, but seperate=20 issue. > | Snarky response aside, I read the src (note the env screwups I've=20 > | pointed out, and the fact y'all don't support try eclass unified=20 > | overlays), and your documentation- the point was that paludis can=20 > | only be used for new installs, and you're locked to paludis as your=20 > | pkg manager at that point without a translation script. >=20 > 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=20 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. =20 Your repositories support specifying an arbitrary eclass- they do not=20 support the standard unification on the fly of eclass that most=20 portage users use- *technically* it can be done via copying eclasses=20 =66rom each repo into an eclass directory (better yet symlinks), but=20 that's not unifying- that's working around the implementation. Simple example, eclasses in overlay X must override PORTDIR y, no=20 eclass in X, check Y. If paludis supports that common usage model, kindly point it out=20 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? > |=20 > | We can't do anything about that idiocy. > |=20 > | That doesn't mean a profile should be added to the tree that portage=20 > | is incapable of resolving properly however- simple example would be=20 > | inheriting from two parents, one that's base arch agnostic defaults,=20 > | other is arch specific modifications. >=20 > 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=20 (just because someone else did something stupid doesn't mean you can).=20 It's pretty simple, don't stick stuff into the tree that can silently=20 fail, stick stuff in that is detected instead of silent failures. > | See above. Renaming of PORTAGE_* -> PALUDIS_* vars doesn't strike me= =20 > | as "sillier bugs", strikes me as "we stamped it with our name, thus=20 > | introducing subtle bugs into minor packages like perl". >=20 > We emulate some PORTAGE_ variables. We don't emulate the ones that > aren't necessary. >=20 > | And yes, that's actually a valid example- easy to spot via just a=20 > | simple grepping of the tree (I suggest you do so). >=20 > Heh. You lose. It isn't. look in the files directory- specifically modifies extmaker to be=20 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=20 > | without a damn good reason. >=20 > 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=20 gentoo users sans the few paludis experimenters cannot use N profile=20 inheritance, and portage will misbehave with it. Wrong profile is=20 pretty damn obvious (compilation failure)- partially loaded profile is=20 a bit different however, you only get part of the profile tree loaded=20 (likely enough to continue on), but not all of it's settings. Bit retarded here, but seriously, work it out in the overlay (like=20 most herds do), then try to bring it to the tree. > | Bluntly, you break compatibility with vdb/tree, paludis has no real=20 > | future with gentoo beyond forking- requiring 100,000 users to=20 > | reinstall because you don't want to do backwards compatibility is=20 > | daft. >=20 > 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=20 > | "portage sucks"), getting back to it, paludis is incompatible with=20 > | portage at the actual ebuild level- considering that, why should the=20 > | tree be modified to add a profile that's just going to introduce=20 > | further breakage? >=20 > 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=20 render it incompatible, and the response is "portage does it worse"? =20 Portage doesn't willy nilly convert/drop vars, nor screw with the env=20 handling. Env handling *is* a bitch to get it properly- the ebd based=20 portage-2.1 already demonstrated it, and all that was doing was=20 *fixing* the statefullness of the env, not hacking all local data out. That and the thread is getting fairly wide in discusion, rather then=20 the profile specific "does alt pkg manager X cruft belong in the=20 tree?" ~brian --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEai4fvdBxRoA3VU0RAshDAJ4zQIHMUyQp+h6dqPWk2G9HN0TxRwCgzjga 2CPVZBtemf4fXzkUBRZ1Ih0= =ZCHj -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- -- gentoo-dev@gentoo.org mailing list