Re: [gentoo-dev] Default Ebuild behaviour
Alin Nastac wrote: Well, the only reason squid installs a cron/logrotate file is because of the sentence quoteyour package ... is supposed to just work for the end-user/quote, which at that moment I understood it as a requirement. Without it, a fresh squid install needs to be tweaked by the user (unless you don't mind to have an ever increasing /var/log/squid/* log files). Just a comment: Uhm, I think squid does its own logrotation, if the USE logrotate isn't enabled for squid when building it. /Andreas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default Ebuild behaviour
Andreas Vinsander wrote: Alin Nastac wrote: Well, the only reason squid installs a cron/logrotate file is because of the sentence quoteyour package ... is supposed to just work for the end-user/quote, which at that moment I understood it as a requirement. Without it, a fresh squid install needs to be tweaked by the user (unless you don't mind to have an ever increasing /var/log/squid/* log files). Just a comment: Uhm, I think squid does its own logrotation, if the USE logrotate isn't enabled for squid when building it. And there I go hide in shame... should have read the other thread about logrotate USE flag first... /Andreas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default Ebuild behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 lo, On Tuesday 31 January 2006 17:24, Ciaran McCreesh wrote: | 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. Surely that so long as it is optional then that is implicitly accepted if they chose to use it. Noo! 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. This sounds like something particular to your configuration and usage rather then a problem for everyone. I'll accept that more files will equate to some performance hit, but not something that most people will be seriously impacted by. 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. Thats precisely my point (well the other part of the point was that there are a lot of ebuilds that are NOT working after an emerge and they should)! I want to see a consistant way of handling the extras. | 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. No! The educated decisions include how everyone else is handling the issue. Thats the thing, everyone is not handling the issue in the same manner. 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. Thats where I want to go with this, get agreement, get it ratified, make it policy and start enforcing it. Policies after all, should come into existance to help achieve something, not as a hinderance. I'm only pushing this because I think having a policy on this matter WOULD make things better for everyone. - -- Benjamin Smee (strerror) crypto/forensics/netmail/netmon -BEGIN PGP SIGNATURE- Version: GnuPG v1.9.20 (GNU/Linux) iD8DBQFD4JB4AEpm7USL54wRAidsAJ0dqYc9yvhpqyzujBLLlVoMaUlM+wCfVwWR pQPf8np5sCPeJaNmaEr8i5w= =6wuc -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, 2006-01-31 at 12:15 -0800, Donnie Berkholz wrote: I finally came up with an idea for this that satisfies my desire to not recompile the package to get e.g. a logrotate file. Have the flag control whether it's installed to /etc or to /usr/share/doc. +1 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, 31 Jan 2006 12:11:49 + Benjamin Smee (strerror) [EMAIL PROTECTED] wrote: | While I understand various developers concerns about cluttering /etc | (especially embedded), I don't see why this should stop the policy of | writting ebuilds that work and have expected tools around them. | Precisely what that constitutes is the real question. See, you're not really taking into account the cost of sticking files in /etc. For packages where an etc entry is low cost, it's already done. For things like bash completion and log rotation, the cost of installing a file into /etc can be extremely high, so it shouldn't be forced upon system administrators unless they ask for it. The same goes for cron entries for packages where the cron part isn't a core operation. What would be nice is a ban on .example files in anywhere covered by CONFIG_PROTECT. We have /usr/share/doc/ for those. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 heya, On Tuesday 31 January 2006 12:31, Ciaran McCreesh wrote: See, you're not really taking into account the cost of sticking files in /etc. For packages where an etc entry is low cost, it's already done. What is the cost you are referring to specifically? I think I know but I'd like a specific definition. For things like bash completion and log rotation, the cost of installing a file into /etc can be extremely high, so it shouldn't be forced upon system administrators unless they ask for it. The same goes for cron entries for packages where the cron part isn't a core operation. Agreed, the question then though is how to manage it. Is USE the right way? Given that there will always be a couple of exceptions, is it not reasonable to expect that all packages that install cron entries do it in a consistant manner? (and for a moment can certain peoples fear of breaking existing installations be put aside, we are paralysed if we let fear govern what we will consider, if we did decide on something that might ostensibly break existing installations or cause needless recompiles we can address those concerns via work around means if necessary once a standard has been decided on). What would be nice is a ban on .example files in anywhere covered by CONFIG_PROTECT. We have /usr/share/doc/ for those. Agreed. Personally I think example files belong in /usr/share/doc, but I also think that config files should be written out to the correct dirs and external tools like etc-update/dispatch-conf be used to manage them. - -- Benjamin Smee (strerror) crypto/forensics/netmail/netmon -BEGIN PGP SIGNATURE- Version: GnuPG v1.9.20 (GNU/Linux) iD8DBQFD3248AEpm7USL54wRAovuAJ40BsTPlabOLD2ODppilSdOdjQ/sgCeK40o 9PK6bmUlFY72fEBoKnTSGx8= =5ibW -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, 31 Jan 2006 14:03:38 + Benjamin Smee (strerror) [EMAIL PROTECTED] wrote: | On Tuesday 31 January 2006 12:31, Ciaran McCreesh wrote: | See, you're not really taking into account the cost of sticking | files in /etc. For packages where an etc entry is low cost, it's | already done. | | 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. 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... 3. Performance. Entries in /etc can have a serious performance impact. The easy example is bash completion, which can be reaaaly slow if you have a few hundred entries. 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. | Agreed, the question then though is how to manage it. Is USE the | right way? Given that there will always be a couple of exceptions, is | it not reasonable to expect that all packages that install cron | entries do it in a consistant manner? Not really. For some packages, cron files must always be installed for proper operation. For some packages, cron files are strictly optional extras for features that many users will not want. For many it's somewhere in between. For packages in the first group, a USE flag is silly. For packages in the second group, not using a USE flag is silly. For the in-between cases, that's one of those areas where the ebuild maintainer has to make an educated decision. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
-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 reaaaly 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
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, 31 Jan 2006 17:06:35 + Benjamin Smee (strerror) [EMAIL PROTECTED] 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. | | 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 | reaaaly 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. Noo! 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 | 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 | 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. 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. | | 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. | | 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. No! 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. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, 2006-01-31 at 15:47 +, Ciaran McCreesh wrote: Not really. For some packages, cron files must always be installed for proper operation. For some packages, cron files are strictly optional extras for features that many users will not want. For many it's somewhere in between. For packages in the first group, a USE flag is silly. For packages in the second group, not using a USE flag is silly. For the in-between cases, that's one of those areas where the ebuild maintainer has to make an educated decision. Personally, I would prefer USE *not* be used for this. As I understand it, USE is for optional dependencies/support in a package. The logrotate USE is a good example of this not being the case. The package has logrotate support already, or the logrotate file's existence is not tied in any way to what the package was compiled with (squid being the obvious exemption here). Basically, if the package *requires* something to function, such as a cron script, then it should install it unconditionally. If it does not, then it shouldn't install it. Having to change USE to get a stupid cron/logrotate file is definitely not the best option. Why not install it to /usr/share/doc/$package as $package.logrotate and tell the user about it instead? The only case mentioned where the logrotate USE flag changes functionality is squid, so it should keep the logrotate local USE and everything else should drop it, then copy the logrotate files into /usr/share/doc. That way I don't have to --newuse and recompile a package just to get a simple example logrotate file, things don't get shoved into /etc without consent, and everybody is happy, right? (Yeah right... :P) -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Default Ebuild behaviour
Chris Gianelloni wrote: Basically, if the package *requires* something to function, such as a cron script, then it should install it unconditionally. If it does not, then it shouldn't install it. Having to change USE to get a stupid cron/logrotate file is definitely not the best option. Why not install it to /usr/share/doc/$package as $package.logrotate and tell the user about it instead? The only case mentioned where the logrotate USE flag changes functionality is squid, so it should keep the logrotate local USE and everything else should drop it, then copy the logrotate files into /usr/share/doc. That way I don't have to --newuse and recompile a package just to get a simple example logrotate file, things don't get shoved into /etc without consent, and everybody is happy, right? (Yeah right... :P) Well, the only reason squid installs a cron/logrotate file is because of the sentence quoteyour package ... is supposed to just work for the end-user/quote, which at that moment I understood it as a requirement. Without it, a fresh squid install needs to be tweaked by the user (unless you don't mind to have an ever increasing /var/log/squid/* log files). As for --newuse forced recompilation of squid, do you think people will just keep switching logrotate USE flag? Agreed, it could happen once, but that's it! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Default Ebuild behaviour
Ciaran McCreesh wrote: On Tue, 31 Jan 2006 17:06:35 + Benjamin Smee (strerror) [EMAIL PROTECTED] wrote: | On Tuesday 31 January 2006 15:47, Ciaran McCreesh wrote: | 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 packages where /etc entries are wanted by some, not wanted by some, yes. I finally came up with an idea for this that satisfies my desire to not recompile the package to get e.g. a logrotate file. Have the flag control whether it's installed to /etc or to /usr/share/doc. Thoughts? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, Jan 31, 2006 at 12:15:00PM -0800, Donnie Berkholz wrote: I finally came up with an idea for this that satisfies my desire to not recompile the package to get e.g. a logrotate file. Have the flag control whether it's installed to /etc or to /usr/share/doc. That's actually a pretty good compromise, if you ask me. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpisVJSq5nPc.pgp Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, 31 Jan 2006 12:15:00 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | I finally came up with an idea for this that satisfies my desire to | not recompile the package to get e.g. a logrotate file. Have the flag | control whether it's installed to /etc or to /usr/share/doc. | | Thoughts? I'd prefer either /etc or /etc and /usr/share/doc personally. But yeah, that's a nice solution. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, Jan 31, 2006 at 10:53:28PM +, Ciaran McCreesh wrote: I'd prefer either /etc or /etc and /usr/share/doc personally. But yeah, that's a nice solution. You mean either /usr/share/doc or /etc/ and /usr/share/doc? ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgp5ezFne0LXo.pgp Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
Donnie Berkholz wrote: Ciaran McCreesh wrote: On Tue, 31 Jan 2006 17:06:35 + Benjamin Smee (strerror) [EMAIL PROTECTED] wrote: | On Tuesday 31 January 2006 15:47, Ciaran McCreesh wrote: | 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 packages where /etc entries are wanted by some, not wanted by some, yes. I finally came up with an idea for this that satisfies my desire to not recompile the package to get e.g. a logrotate file. Have the flag control whether it's installed to /etc or to /usr/share/doc. Thoughts? +1 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default Ebuild behaviour
On Wed, 1 Feb 2006 00:03:46 +0100 Henrik Brix Andersen [EMAIL PROTECTED] wrote: | On Tue, Jan 31, 2006 at 10:53:28PM +, Ciaran McCreesh wrote: | I'd prefer either /etc or /etc and /usr/share/doc personally. But | yeah, that's a nice solution. | | You mean either /usr/share/doc or /etc/ and /usr/share/doc? Uh, yeah. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, Jan 31, 2006 at 11:17:49PM +, Ciaran McCreesh wrote: On Wed, 1 Feb 2006 00:03:46 +0100 Henrik Brix Andersen [EMAIL PROTECTED] wrote: | On Tue, Jan 31, 2006 at 10:53:28PM +, Ciaran McCreesh wrote: | I'd prefer either /etc or /etc and /usr/share/doc personally. But | yeah, that's a nice solution. | | You mean either /usr/share/doc or /etc/ and /usr/share/doc? Uh, yeah. Good idea. ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpjJ2BCpLKcN.pgp Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
maillog: 31/01/2006-12:15:00(-0800): Donnie Berkholz types Ciaran McCreesh wrote: On Tue, 31 Jan 2006 17:06:35 + Benjamin Smee (strerror) [EMAIL PROTECTED] wrote: | On Tuesday 31 January 2006 15:47, Ciaran McCreesh wrote: | 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 packages where /etc entries are wanted by some, not wanted by some, yes. I finally came up with an idea for this that satisfies my desire to not recompile the package to get e.g. a logrotate file. Have the flag control whether it's installed to /etc or to /usr/share/doc. Install it always in /usr/share/doc and use pkg_config() to copy it over to /etc? Isn't stuff like that what pkg_config() is supposed to do anyway? -- (* Georgi Georgiev (* A little suffering is good for the soul. - (* *)[EMAIL PROTECTED]*) - Kirk, The Corbomite Maneuver, stardate *) (* http://www.gg3.net/ (* 1514.0 (* pgpjlnPuQc0Ys.pgp Description: PGP signature
