From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NKItI-0000ud-Gz for garchives@archives.gentoo.org; Mon, 14 Dec 2009 21:55:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1088DE0A81; Mon, 14 Dec 2009 21:55:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B924FE0A81; Mon, 14 Dec 2009 21:55:36 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 0FCD467BDF; Mon, 14 Dec 2009 21:55:36 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: Ciaran McCreesh Subject: Re: [gentoo-council] Re: [gentoo-pms] kdebuild-1 conditionales Date: Mon, 14 Dec 2009 16:56:49 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31.4; KDE/4.3.4; x86_64; ; ) Cc: gentoo-council@lists.gentoo.org, Ulrich Mueller , Brian Harring , gentoo-pms@lists.gentoo.org References: <20091210214848.7d070ab2@gentoo.org> <200912141201.04887.vapier@gentoo.org> <20091214182129.159de745@snowcone> In-Reply-To: <20091214182129.159de745@snowcone> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-council@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2897771.CELtCGKX2I"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200912141656.51004.vapier@gentoo.org> X-Archives-Salt: 0272179f-b253-4efd-8491-a66f8915daa2 X-Archives-Hash: 6c611590f3feef8715e7de3ba2054975 --nextPart2897771.CELtCGKX2I Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Monday 14 December 2009 13:21:29 Ciaran McCreesh wrote: > On Mon, 14 Dec 2009 12:01:03 -0500 Mike Frysinger wrote: > > > Keeping it around without a specification is a bad idea. And no, the > > > plan is not to keep it anywhere forever. The plan is to keep it > > > around until we can ensure that users aren't going to be affected > > > by the removal. > > > > which is irrelevant to the PMS. fact is, only your PM supports it > > and no one is telling you what to do with your PM. correctly > > removing it from PMS wont affect any user whatsoever. absolutely no > > users would be affected by cleaning up the PMS git tree. >=20 > As has already been explained, keeping the spec around is a necessary > part of keeping the implementation around. that is purely your own decision. having it in PMS has 0 bearing on it. =20 kdebuild behavior isnt going to magically change semantics with=20 pkg_{pre,post}rm and if it does, it isnt going to because someone changes i= t=20 behind your back. i'm sure you're more than capable of watching the change= s=20 going into your PM. > > as for "it's what the official KDE docs said", that too is complete > > bs. there are teams with more important ebuilds that have > > instructions that only work with portage. >=20 > I highly doubt that, since if that were the case we'd be receiving > reports from users about it. i guess i'm not a user and my multislot bug doesnt exist. and my=20 CBUILD/CTARGET reports were discarded. prepstrip i dont think i bothered=20 pushing because of your insistence on ignoring prep* functions. having bro= ken=20 PM (where PM !=3D portage) behavior is what you get then; no sweat off my b= ack. > > if anyone tried to add these to the PMS, you'll fully bitch and moan > > and block it from ever making it into the PMS. some of these rely on > > portage behavior with the environment and some of these rely on > > behavior portage has had for years (and before the PMS). >=20 > Er, no. If that were the case, users wouldn't be able to use Paludis. funny how you use a logic statement in defense of your PM, but then at the= =20 same exact time use it to block other PMs. how you manage this constant=20 circular logic is beyond me. > > > Uh. Riiiiight. I'm just drowning in bug reports from users who're > > > using ebuilds that break with Paludis because we haven't > > > implemented things that've been used in the tree for years. Perhaps > > > you'd care to back up your mud-slinging with some examples. > > > > stop with your misdirection bullshit. you know plenty of examples. > > then again, your style is to keep whining that you arent aware of > > anything until someone explicitly mentions them, so there's prep*, >=20 > prep* can't go in since what it does has yet to be locked down or > guaranteed. We can't spec it as "does something arbitrary", yet that's > all prep* is guaranteed to do. And, as you know, EAPI 4 has had > features added to it to give you what you were after, except done in a > well defined manner. i dont recall anyone going over a replacement for prepstrip. the toolchain= =20 packages have been using this interface for quite a while and rely on it=20 working correctly. current git master doesnt seem to mention anything wrt= =20 stripping behavior. > > FEATURES >=20 > There is no legitimate use for FEATURES in the tree, since something > being in FEATURES only indicates that the user asked for it, not that > it is enabled. For example, ebuilds that do has userpriv $FEATURES are > broken, because userpriv in features does not mean that userpriv has > actually been enabled by Portage. i never said the code/design was clean. i did however say that we have=20 defacto spec that people are relying on and it isnt in PMS and you block it= ,=20 yet specs that was explicitly never approved and never in the tree you had = no=20 problem adding. > > and CBUILD/CTARGET in econf to mention a few. >=20 > Could you point me to the bug for that one please? I think I can see > what PMS might be missing on that one, but I don't recall ever seeing a > bug about it, or what the conclusion was. I also can't find the bug by > searching for comments containing all of the words "pms ctarget", or > "pms cbuild". i told you about it in the very first draft review of PMS and you told me i= t=20 had no business in the PMS and it was a portage-specific feature. i had to= =20 bitch and moan to even get mentioned as reserved so it wouldnt be arbitrari= ly=20 hijacked by stupid people. here's the notes from my initial review i gave you oh-so-long ago and you=20 responded on irc at the time (no, i dont have irc logs because i dont log=20 anything): http://dev.gentoo.org/~vapier/PMS-notes > > > > it doesnt belong there, it never has, so delete it/branch it > > > > already. > > > > > > You still haven't explained why it's better to delete it now than > > > to do a controlled removal that won't affect users. > > > > and you have yet to show how your PM behavior is relevant one bit to > > the PMS here. removing unofficial crap from the PMS has no bearing > > whatsoever on ebuilds that require unofficial PMs. keep the crap in > > your PM forever for all i care. >=20 > Uh. See earlier emails in the thread. not much point when you have no justification for why it needs to be kept =2Dmike --nextPart2897771.CELtCGKX2I Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iQIcBAABAgAGBQJLJrSiAAoJEEFjO5/oN/WBV1kP/1AG7Sju5gB8pN8vDZ9FYm7Y rCBRPPqJ5ncUnmTjC+Vqz7K3h2EOIwiiT9nLkGzO26W9ufYEz8NEwH3fejWjY+Mg QhDHcwqxrSmj9BIlIHvYCQwR5LySBGw8VJM/cQLL3gRwcHCL0ztMiG9IDpDAVlTy tRnNZpWvE0xcNkzIU2sAjATeOB8lIRV0i+lP66I2naLrpBb0qsHUuuaMujNbhWl7 rpeyBcggNA5m4Di4/8XiWLOxKbqOIXTYmPNTByGaFofIPIAYZcNRbCxh4Ko+JDTu wHqdc6p3uEXtm4LZHtJpjZ/AEZZlDXjPIzpbvM0YIRRTcJbt0Aav+uqt6eijfloq 3OYL3We1HQQm+BzPxp6a5xNhBH6E0ebhA7/dK45pnmFRR8gziGbarroZ7gBCt86e NumWFLr8Zrl0ouVJrFAyO5aTW89dK+eYBk1rM6k21pF3utSySLwDI0nlbrromVjD pLnCzNALEKXNQY44wap3pX8MvpAXYlgfsmqUPFTf3IPficEYX9Fp8G4FXjUL/3+k +JisyTn0sTAE0EB23u9DlLro+/Bi/KS23pv8IOtWwLqMd/oBG+ngLUAhREcNWx+g e+K9xqPCAlTmB5PvrV+UBuiUyMHS6rv29IhEOxduEk4NcOpOJgvxbJ2QMbOtarap n1oQnRxuyhU0tdeC1Qpd =4d5F -----END PGP SIGNATURE----- --nextPart2897771.CELtCGKX2I--