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.54) id 1F3zT9-0007sX-B5 for garchives@archives.gentoo.org; Tue, 31 Jan 2006 17:39:07 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k0VHc5n1019477; Tue, 31 Jan 2006 17:38:05 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k0VHYr2u018229 for ; Tue, 31 Jan 2006 17:34:53 GMT Received: from [213.121.151.206] (helo=snowdrop.home) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1F3zFL-0001d0-IP; Tue, 31 Jan 2006 17:24:51 +0000 Received: from localhost ([127.0.0.1] helo=snowdrop.home) by snowdrop.home with esmtp (Exim 4.54) id 1F3zFH-00032z-1j; Tue, 31 Jan 2006 17:24:47 +0000 Date: Tue, 31 Jan 2006 17:24:42 +0000 From: Ciaran McCreesh To: "Benjamin Smee (strerror)" Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Default Ebuild behaviour Message-ID: <20060131172442.5c878a3d@snowdrop.home> In-Reply-To: <200601311706.38570.strerror@gentoo.org> References: <200601311211.59355.strerror@gentoo.org> <200601311403.40320.strerror@gentoo.org> <20060131154702.11a027ad@snowdrop.home> <200601311706.38570.strerror@gentoo.org> X-Mailer: Sylpheed-Claws 2.0.0-rc4 (GTK+ 2.8.10; i686-pc-linux-gnu) 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; boundary=Sig_BBdAQqWWXKyMTZUXqDs3ucM; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 527f7d6b-012a-4605-8322-ac2ece01c85a X-Archives-Hash: 34541073ff152e16f1c6beaae8b73ef3 --Sig_BBdAQqWWXKyMTZUXqDs3ucM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 31 Jan 2006 17:06:35 +0000 "Benjamin Smee (strerror)" wrote: | On Tuesday 31 January 2006 15:47, Ciaran McCreesh wrote: | > | What is the "cost" you are referring to specifically? I think I | > | know but I'd like a specific definition. | > | > 1. Management. For example, handling etc-update. |=20 | That is surely a "cost" people have for upgrading an application and | have implicitly accepted by doing so. Not really. There's a basic cost of installing or upgrading an application, but there's also additional cost that comes from optional extras. | > 3. Performance. Entries in /etc can have a serious performance | > impact. The easy example is bash completion, which can be | > reaaallllly slow if you have a few hundred entries. |=20 | I find this hard to swallow. You could say that about any directory | that is over a certain size, say typically /dev. Thats even on the | assumption that most people use bash completion constantly or that on | modern hardware it is a noticeable problem, which in my experience is | not the case. Noooooo! Not the cost from using a sucky filesystem. The cost from your application of choice having to parse all those files. Bash is a good example -- it's not particularly fast (read: very slow) at parsing scripts, and if you have a zillion bash completion scripts installed then something as simple as starting a terminal can take a very long time. It's precisely this that lead to bash-completion-config. | Then change the default configuration so that it only updates for the=20 | directories that you want. The expectation that a package works after | an emerge is in 99% of cases perfectly reasonable, and if its not | perfect for one persons particular environment then the onus is on | them to fix it. We can't be everything to everyone, but we can have a | good shot at getting close in most cases. Sure, packages are expected to work after installation. Does providing a cron entry count as part of working? Not for some packages. Does installing a bash completion entry count as part of working? Not for most packages. No-one (sane, anyway) is opposed to decent default config files going into /etc automatically where such a thing is possible. The question is how to handle the high cost extras. | > For packages in the first group, a USE flag is=20 | > silly.=20 |=20 | Why, there may be cases where what you think should require cron, | doesn't for that particular user and besides which again we are | talking about a tiny minority from what I can see. If that's the case, either your package isn't in the first category or the user is doing something especially weird. Users doing especially weird things are on their own. | > For packages in the second group, not using a USE flag is silly.=20 |=20 | I take it you are agreeing we should have a USE flag for these | ebuilds? For packages where /etc entries are "wanted by some, not wanted by some", yes. | > For the in-between cases, that's one of those areas where the ebuild | > maintainer has to make an educated decision. |=20 | and here is the nature of the problem imho. Currently everyone is | making these educated decisions and it means there is no coherency at | all. Nooooo! The educated decisions include "how everyone else is handling the issue". | Why not say something like "Where possible, all ebuilds should | work after being emerged. Example configuration files should be | installed in /usr/share/doc, and additional administration scripts / | configuration should be done via the global use flag FOO" where foo | is cron or logrotate as an example. I understand that it isn't | perfect for EVERYTHING, but then there is no one solution for | everything, and having something like that would certainly be a lot | clearer to developers and users alike as to how to go about doing | things instead of having to read ewarn / einfo as they fly by on how | to specifically do things for that specific ebuild. Hah, I tried that with devmanual. The problem is, the worst offenders for doing perverse things in ebuilds are the same ones who won't accept any documentation that isn't official and marked mandatory and who will block any documentation of existing practice from becoming policy because it isn't policy. --=20 Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm --Sig_BBdAQqWWXKyMTZUXqDs3ucM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD351e96zL6DUtXhERAi7ZAKCMqIP7flHkz3a6wYZV5A9wepIjpQCfUlYR gfw0J85nVd8drWn4kPdKCLQ= =siTN -----END PGP SIGNATURE----- --Sig_BBdAQqWWXKyMTZUXqDs3ucM-- -- gentoo-dev@gentoo.org mailing list