-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 heya,
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. That is surely a "cost" people have for upgrading an application and have implicitly accepted by doing so. > 2. Administration. Everything in /etc must be checked and covered by > backup policies and the like. Unless you're a home user, in which case > you probably just hope for the best... Sounds similar to point 1, in the case of backups, I'd suggest that most policies would cover the entire box, or at the very least the entire /etc and all its subdirs. In my experience as an admin we always just back up the entire machine, I don't see how adding things in here makes a significant difference for most users, and where it does, eg embedded, they can chose not to install things, via for example, USE. > 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. 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. > Less obvious examples are cron entries > for things like updatedb -- if you have a few dozen chroots and svn > checkouts of large projects, updatedb can take a very long time and eat > a lot of battery power. Then change the default configuration so that it only updates for the 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. > Not really. For some packages, cron files must always be installed for > proper operation. Granted, but that is probably a VERY small number, certainly not a majority and falls under exceptions. > For some packages, cron files are strictly optional > extras for features that many users will not want. Hence USE. > For many it's > somewhere in between. Here we disagree. Give me some numbers, because from my research i'd suggest that while there are some packages in your first category, almost everything else would fall into the second. Again, even if there are some that don't its not going to be many, we are after getting something that will work for as many as possible, some consistancy rather then saying "look there is no one solutation that will be perfect so lets give up now". > For packages in the first group, a USE flag is > silly. 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. > For packages in the second group, not using a USE flag is silly. I take it you are agreeing we should have a USE flag for these ebuilds? > For the in-between cases, that's one of those areas where the ebuild > maintainer has to make an educated decision. 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. 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. - -- Benjamin Smee (strerror) crypto/forensics/netmail/netmon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.20 (GNU/Linux) iD8DBQFD35keAEpm7USL54wRAqcRAJ9PhaIYHPQJ9QD2DfgPBkSBi+Af9ACffAUl CLB4LC/8BRaH0qL1jwsUuQA= =QoCM -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list
