From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F3DEA1381F3 for ; Sun, 16 Jun 2013 11:54:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BE795E094F; Sun, 16 Jun 2013 11:54:32 +0000 (UTC) Received: from juliette.telenet-ops.be (juliette.telenet-ops.be [195.130.137.74]) by pigeon.gentoo.org (Postfix) with ESMTP id BE263E08EA for ; Sun, 16 Jun 2013 11:54:31 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by juliette.telenet-ops.be with bizsmtp id ozuW1l00S2khLEN06zuWgX; Sun, 16 Jun 2013 13:54:30 +0200 Date: Sun, 16 Jun 2013 13:51:50 +0200 From: Tom Wijsman To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update)) Message-ID: <20130616135150.57005bf3@TOMWIJ-GENTOO> In-Reply-To: References: <20130616093322.GB20905@waltdnes.org> <20130616122154.47c8a591@TOMWIJ-GENTOO> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/y0V/M08PKBx55+5Y0H1BbQJ"; protocol="application/pgp-signature" X-Archives-Salt: 7990f78c-cc1c-4a46-8d63-1837343f62ad X-Archives-Hash: 91c57732bc2165b58cfc4ad5c20b4013 --Sig_/y0V/M08PKBx55+5Y0H1BbQJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 16 Jun 2013 06:53:07 -0400 Rich Freeman wrote: > I have mixed feelings. While on one hand it might be cleaner to be > able to separate upstream files from gentoo files (openrc scripts, > tmpreaper, logrotate, etc), the fact is that these options files do > introduce functional changes of some kind. An optional file that 99% > of users get installed by default that is a cron script could have a > big impact on users of a package. Do we really want stuff like that > happening with no maintainer involvement at all? Remember that those optional files are used to make the package work for the user where it would otherwise not work. No maintainer involvement for those is fine; since the optional files bring the package from a not working state to a working state for the user. We could make cron files an exception to this approach as they introduce more behavior than just making the service work in general. In most occasions I think optional files don't require the package maintainer to do anything to the package itself, if however the package itself doesn't support the optional file (eg. no means to start it as a daemon) it is up to the package maintainer to decide whether or not to patch that; note that this paragraph is different from the maintainer involvement you had in mind, but I'm mentioned because it came to mind. > I think cooperation makes more sense than having people work around > each other deliberately ignoring things they don't like. Cooperation that has lead to ~4 developers rage quitting, who's next? What if all the threads we saw are a consequence of a bad pkg structure? I think we should be able to implementing different not conflicting choices instead of forcing the package maintainer to do something, the current package structure doesn't really fit well for that as we saw; people can't always happily cooperate on everything, that's by design... > The logic around installing these files could get convoluted as well. Maybe, maybe not; that's what we need to inspect over the days to come. > What if a line in the file has to be set dynamically based on > something detected at time of installation? Is there an example of this? Assuming there is a need for this, we could allow bash files to do these kind of things, see it as some kind of mini ebuilds in the optional directory; it's kind of like the idea of creating separate X-SomeInitSystem packages, but then without cluttering the output of search utilities (eg. emerge --search, eix) and the need to fork the actual package logic itself, but rather just implement the diference. ;) > What if the file varies by package version? This could be covered using the installation conditionals. > With an ebuild such things are straightforward - do we need > essentially a second src_install just to work around the fact that > somebody doesn't want us touching the main one? Either you go for one end (above suggested approach), the other end (no ownership of an ebuild) or in between (discussion, rage and quits). I think it is now the right moment in time to decide whether we want to go for a specific end or just rather stay where we are. I just hope to not see all three approaches to be discussed to death in the future. Neither do I want to see DevRel / CoC / Council kick people out of the project that apart from the matter contribute just fine; however, I do think they should deal with abusive / ignorant / ... behavior where the necessary explanation behind silence or bold statements are missing. > If this were about cleaner separation/maintenance of upstream vs > gentoo stuff I could see the benefit (though it needs refinement). Definitely needs refinement, I originally planned to carefully type this out as a GLEP proposal; but given someone else mentioned it, I decided to throw the reasoning in here to help the discussion that might be about to start here and to see some useful feedback. > However, this really seems like a technical workaround for a people > problem. Maybe, maybe not; I'm just bringing it to light to get people thinking about the ideas behind this, maybe someone comes up with alternatives. > Also, I think that Douglas is right about something - this really > isn't THAT big of a problem.=20 It definitely isn't, but if developers quit; it does bother them. > It really only involves a few people and a single issue. I'm not so sure about that; there will certainly me more issues in the future, and there might be some people that haven't complained yet. People not following the ML, people not reading systemd threads, ... > I think the bigger barrier to getting systemd units (or whatever) > into the tree is people willing to do the work. I should have > committed a systemd unit for mythtv ages ago, and I'm just too lazy > to get it done... :) If I learn how to write optional files properly; I would like to be able to use that knowledge for more than the low amount of daemon packages I maintain, but rather contribute to a larger share of packages. If I can't go contribute to more packages, what would I learn it for? I would only be lazy if I couldn't put my knowledge to better use. Furthermore, I think endless discussions, rage and quits shouldn't be part of the progress to sanely add optional files to the Portage tree. --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/y0V/M08PKBx55+5Y0H1BbQJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJRvabcAAoJEJWyH81tNOV9UlAIALDkomPjD3xSrikz7U1+iWlI 8VCEbOmfsN3JoeOGTpfES+A5tJVyCyqlqvlW4t8O7NTkyLpX0Z2zpoTYYcnQhWHV k8Tu6zYOYSobJbM0Vnf03bIBVrThFP7iS2F6nXIQYqVrip/dtHadTs448D5LMYzT jHWf3MjB2x1Na3FSc3tklhfQN2eQctsHNjLkICs62VdVaigzX5r3M1p97XHdCF2l b6mgUyTr1uq0m+ibeXqAlLEc1ha7tKP2G53I9cJSJEBg88Uhf5nI2vX936gL2pTP yMZy7ghPVslKh0btbcmZWBeGtHA61W2g08v0nWKodxoyHXj7EAEUmo9lo6Ry2BA= =Esjt -----END PGP SIGNATURE----- --Sig_/y0V/M08PKBx55+5Y0H1BbQJ--