| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Heya, |
| 5 |
|
| 6 |
I noticed the logrotate USE flag thread recently and did a bit of reading on |
| 7 |
the problem (ie read all the previous threads) as well as touching on the |
| 8 |
whole cron USE flag thoughts as well, and it struck me that it is really odd |
| 9 |
that this entire issue hasn't been sorted out a long time ago. I was always |
| 10 |
under the impression that our ebuilds should work, in whatever capacity that |
| 11 |
is possible, after being emerged. I did a little digging and found: |
| 12 |
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1 |
| 13 |
Under 1a, the third point states: |
| 14 |
"Your package, when complete and unmasked, is supposed to "just work" for the |
| 15 |
end-user. Tweaking the installed product to get it to work should be |
| 16 |
optional; thus you need to install the package with reasonable default |
| 17 |
settings." |
| 18 |
|
| 19 |
This strikes me as sane, lets face it, while many people are of the opinion |
| 20 |
that before using a package, say AIDE, that you should know all about it and |
| 21 |
read all the documentation then spend time writing a configuration file, most |
| 22 |
people will just want to emerge an integrity checker and have something |
| 23 |
working. Additionally it seems to me that tools like etc-update and |
| 24 |
dispatch-conf were written to manage maintaining configuration files. While I |
| 25 |
understand various developers concerns about cluttering /etc (especially |
| 26 |
embedded), I don't see why this should stop the policy of writting ebuilds |
| 27 |
that work and have expected tools around them. Precisely what that |
| 28 |
constitutes is the real question. |
| 29 |
|
| 30 |
My concern right now is that we have no common way of dealing with ebuilds. |
| 31 |
Some ebuilds work after an emerge, some don't, some have example config files |
| 32 |
but they require the user to copy it over and modify it, some ebuilds have |
| 33 |
{cron,logrotate} entries that they just install, some use a USE flag, some |
| 34 |
don't even have any of the above when you would reasonably expect them to and |
| 35 |
so on. The point is that because of the lack of enforcement on whether |
| 36 |
ebuilds should work after an emerge and what that means (ie does it include |
| 37 |
things you expect as a sysadmin? logrotate and cron entries would normally |
| 38 |
qualify as such, especially for example logrotate for syslog-ng) we have a |
| 39 |
completely inconsistant user experience, each time someone emerges an ebuild |
| 40 |
its unclear what the user has to do, if anything, to make the application |
| 41 |
work. |
| 42 |
|
| 43 |
Is it possible to get a clear statement of policy (if the point I already |
| 44 |
quoted isn't already) as to what state the ebuild should leave the system |
| 45 |
after installation. Can we get agreement as to how to treat configuration |
| 46 |
files, either directly related to the ebuild or subsidary ones like cron / |
| 47 |
logrotate / selinux ? I think that doing so would significantly improve the |
| 48 |
consistancy of Gentoo which would be a win all round. |
| 49 |
|
| 50 |
I know that there are always some exceptions but I believe that having |
| 51 |
working configuration files and consistant treatment of various supporting |
| 52 |
scripts should be perfectly possible for the vast majority of ebuilds. |
| 53 |
|
| 54 |
- -- |
| 55 |
Benjamin Smee (strerror) |
| 56 |
crypto/forensics/netmail/netmon |
| 57 |
-----BEGIN PGP SIGNATURE----- |
| 58 |
Version: GnuPG v1.9.20 (GNU/Linux) |
| 59 |
|
| 60 |
iD8DBQFD31QPAEpm7USL54wRAiRSAJ9AdBPy2LNtznWT564gkkEYWT7PwACffayk |
| 61 |
sDVgyQfdCm81J04Fvc2Z21I= |
| 62 |
=u/cy |
| 63 |
-----END PGP SIGNATURE----- |
| 64 |
-- |
| 65 |
gentoo-dev@g.o mailing list |
Archives