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 1OkYM4-0008Sk-DP for garchives@archives.gentoo.org; Sun, 15 Aug 2010 08:14:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8E0C8E08D6; Sun, 15 Aug 2010 08:13:57 +0000 (UTC) Received: from tommyserver.de (unknown [85.14.198.50]) by pigeon.gentoo.org (Postfix) with ESMTP id 90D2FE087C for ; Sun, 15 Aug 2010 08:13:51 +0000 (UTC) Received: from [192.168.178.22] (p4FDF062A.dip0.t-ipconnect.de [79.223.6.42]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tommyserver.de (Postfix) with ESMTPSA id 19994F27D77 for ; Sun, 15 Aug 2010 10:13:54 +0200 (CEST) Message-ID: <4C67A1BC.4020703@gentoo.org> Date: Sun, 15 Aug 2010 10:13:48 +0200 From: Thomas Sachau Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild References: <20100806212139.9E8422CE15@corvid.gentoo.org> <20100814131013.GA1363@linuxized.com> <20100814134739.GA4529@Mystical> <201008141826.48995.bangert@gentoo.org> <20100814173556.GA26951@boostbox> In-Reply-To: <20100814173556.GA26951@boostbox> X-Enigmail-Version: 1.0.1 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig44BA3FCFBCB5620E037BB928" X-Archives-Salt: 2a5bf485-1bb7-44e5-9e6f-19528c5505d7 X-Archives-Hash: 616340cdd9cd1015cccac5c94f09b7c0 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44BA3FCFBCB5620E037BB928 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 14.08.2010 19:35, schrieb Harald van D=C4=B3k: > On Sat, Aug 14, 2010 at 06:26:12PM +0200, Thilo Bangert wrote: >>> So you want me to force everyone to update the package just to respec= t >>> the LDFLAGS. >> >> yes. IIRC it has been stated on this list before, that a change which = >> changes the resulting binary always needs to be done in a revbump.=20 >=20 > If that's true, that doesn't make sense. Take one extreme case: let's > say libgcj, part of gcc, has a problem with LDFLAGS, and you fixed it. > But the majority of people using gcc don't even turn on java support, > those that do have a working libgcj already, and gcc can easily take > hours to build. Should you revbump? >=20 > There are always exceptions. Maybe you don't consider LDFLAGS support > in general one of those exceptions, but clearly some others do. You > can't just tell them "there are no exceptions" when there are, you need= > to explain why this isn't a valid reason to make an exception. > My impression, too, is that few people care enough about LDFLAGS suppor= t > to want to rebuild packages for it, so I would not have bumped either, > but I'm willing to be convinced I'm wrong. >=20 >=20 This is a nice example, why we should not create fixed rules for everythi= ng, but allow common rules with the usage of common sense. If we now create a rule, which says "Bump= on every change, always and forever", people will complain for big things like gcc, openoffice or= kdelibs. Instead, we have a general rule, which every developer should learn at least from his ment= or to revbump on every change for installed files, but also to use common sense. In the case of = openoffice for example, it does not get a new version or revision for some minor updates, since rebu= ilding openoffice does take much time and resources. The same should apply for your example of LDFLAG= S for gcc, so you can do it without a revbump there or wait, until a version bump comes in and direct= ly add it there. So while general, non-fixed rules may result in some discussions, they al= so allow adjustments in a case by case decision, a fixed "Always revbump" rule creates issues at le= ast for corner cases, in this case packages with very long compile times. --=20 Thomas Sachau Gentoo Linux Developer --------------enig44BA3FCFBCB5620E037BB928 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iJwEAQEKAAYFAkxnocEACgkQG7kqcTWJkGdUkQP/SRBAScZ3LktOecaSmbATZaCS SLmpIx2hp6obFGOFE40NZHJiTJ94F81q7RY5+7dsC9O8Ku3UA/KpOzBfBlvkKLog mhVfKZZ5sMon+5qFUmSN6hwvTrzlAigWMXzw2oC0sWjcbvlbwLKUpEAMg2uhosUr toU9BF6nhUJmLizLK4o= =1lQG -----END PGP SIGNATURE----- --------------enig44BA3FCFBCB5620E037BB928--