[gentoo-dev] Default Ebuild behaviour

[gentoo-dev] Default Ebuild behaviour

[Benjamin Smee (strerror)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Heya,

I noticed the logrotate USE flag thread recently and did a bit of reading on 
the problem (ie read all the previous threads) as well as touching on the 
whole cron USE flag thoughts as well, and it struck me that it is really odd 
that this entire issue hasn't been sorted out a long time ago. I was always 
under the impression that our ebuilds should work, in whatever capacity that 
is possible, after being emerged. I did a little digging and found:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1
Under 1a, the third point states:
"Your package, when complete and unmasked, is supposed to "just work" for the 
end-user. Tweaking the installed product to get it to work should be 
optional; thus you need to install the package with reasonable default 
settings."

This strikes me as sane, lets face it, while many people are of the opinion 
that before using a package, say AIDE, that you should know all about it and 
read all the documentation then spend time writing a configuration file, most 
people will just want to emerge an integrity checker and have something 
working. Additionally it seems to me that tools like etc-update and 
dispatch-conf were written to manage maintaining configuration files. 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.

My concern right now is that we have no common way of dealing with ebuilds. 
Some ebuilds work after an emerge, some don't, some have example config files 
but they require the user to copy it over and modify it, some ebuilds have 
{cron,logrotate} entries that they just install, some use a USE flag, some 
don't even have any of the above when you would reasonably expect them to and 
so on. The point is that because of the lack of enforcement on whether 
ebuilds should work after an emerge and what that means (ie does it include 
things you expect as a sysadmin? logrotate and cron entries would normally 
qualify as such, especially for example logrotate for syslog-ng) we have a 
completely inconsistant user experience, each time someone emerges an ebuild 
its unclear what the user has to do, if anything, to make the application 
work. 

Is it possible to get a clear statement of policy (if the point I already 
quoted isn't already) as to what state the ebuild should leave the system 
after installation. Can we get agreement as to how to treat configuration 
files, either directly related to the ebuild or subsidary ones like cron / 
logrotate / selinux ? I think that doing so would significantly improve the 
consistancy of Gentoo which would be a win all round.

 I know that there are always some exceptions but I believe that having 
working configuration files and consistant treatment of various supporting 
scripts should be perfectly possible for the vast majority of ebuilds.

- -- 
Benjamin Smee (strerror)
crypto/forensics/netmail/netmon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.9.20 (GNU/Linux)

iD8DBQFD31QPAEpm7USL54wRAiRSAJ9AdBPy2LNtznWT564gkkEYWT7PwACffayk
sDVgyQfdCm81J04Fvc2Z21I=
=u/cy
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Default Ebuild behaviour

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

On Tue, 31 Jan 2006 12:11:49 +0000 "Benjamin Smee (strerror)"
<strerror@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Benjamin Smee (strerror)]

-----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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]

On Tue, 31 Jan 2006 14:03:38 +0000 "Benjamin Smee (strerror)"
<strerror@gentoo.org> 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 reaaallllly 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Benjamin Smee (strerror)]

-----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

Re: [gentoo-dev] Default Ebuild behaviour

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 4515 bytes --]

On Tue, 31 Jan 2006 17:06:35 +0000 "Benjamin Smee (strerror)"
<strerror@gentoo.org> 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
| > 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.

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 
| 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.

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.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

On Tue, 2006-01-31 at 15:47 +0000, 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

Ciaran McCreesh wrote:
> On Tue, 31 Jan 2006 17:06:35 +0000 "Benjamin Smee (strerror)"
> <strerror@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

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 <quote>your 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!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

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 <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

On Tue, 31 Jan 2006 12:15:00 -0800 Donnie Berkholz
<spyderous@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

On Tue, Jan 31, 2006 at 10:53:28PM +0000, 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 <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Francesco Riosa]

Donnie Berkholz wrote:
> Ciaran McCreesh wrote:
>> On Tue, 31 Jan 2006 17:06:35 +0000 "Benjamin Smee (strerror)"
>> <strerror@gentoo.org> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

On Wed, 1 Feb 2006 00:03:46 +0100 Henrik Brix Andersen
<brix@gentoo.org> wrote:
| On Tue, Jan 31, 2006 at 10:53:28PM +0000, 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Tue, Jan 31, 2006 at 11:17:49PM +0000, Ciaran McCreesh wrote:
> On Wed, 1 Feb 2006 00:03:46 +0100 Henrik Brix Andersen
> <brix@gentoo.org> wrote:
> | On Tue, Jan 31, 2006 at 10:53:28PM +0000, 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 <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

maillog: 31/01/2006-12:15:00(-0800): Donnie Berkholz types
> Ciaran McCreesh wrote:
> > On Tue, 31 Jan 2006 17:06:35 +0000 "Benjamin Smee (strerror)"
> > <strerror@gentoo.org> 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. - (*
*)    chutz@gg3.net    *) - Kirk, "The Corbomite Maneuver", stardate *)
(* http://www.gg3.net/ (* 1514.0                                     (*

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Default Ebuild behaviour

[Andreas Vinsander]

Alin Nastac wrote:
> 
> Well, the only reason squid installs a cron/logrotate file is because of
> the sentence <quote>your 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]

Andreas Vinsander wrote:
> Alin Nastac wrote:
> 
>>
>> Well, the only reason squid installs a cron/logrotate file is because of
>> the sentence <quote>your 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

[Benjamin Smee (strerror)]

-----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.

> 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.

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.
>
> Nooooo! 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

[Rob Holland]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]