Re: [gentoo-dev] Re: Unmasking modular X
Jason Stubbs <[EMAIL PROTECTED]> said: > On Wednesday 01 February 2006 02:28, Mark Loeser wrote: > > We are talking about completely unrelated versions, not what we are > > touching. > > For example, old imagemagick ebuilds sitting around, where the newer ebuilds > > are fixed, but old ones are not. We have a security bug open about this > > package right now, and having an error about deps in some old version > > doesn't > > really help arch teams at all. > > Security bugs are about the only time I can see any urgency. That's not > a good reason to completely degrade the error though. A switch similar > to --ignore-other-archs that skips certain checks for urgent fixes seems > reasonable though. I don't really see why anyone that is marking an ebuild stable needs to have a fatal error because an older version of that package isn't ported yet. We are perfectly capable of mentioning this on the bug so the maintainer can fix it later :) A flag to ignore it will make me, and probably other archs, happy though. Thanks, -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpX9AeH5oDBd.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
Re: [gentoo-dev] IUSE and LINGUAS?
Jason Stubbs wrote: > Is > having INPUT_DEVICES and the like following the same scheme > (ie, input_devices.desc) acceptable? As long as I can still get the pretty output with -vp. =) Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Tuesday 31 January 2006 22:39, Mike Frysinger wrote: > On Tuesday 31 January 2006 06:31, Jason Stubbs wrote: > > On Monday 30 January 2006 20:54, Ciaran McCreesh wrote: > > > 1. Because for things like LINGUAS, there are arbitrarily many legal > > > values, and documenting them all and keeping the list up to date would > > > be extremely difficult. > > > > "More precisely, how should they be documented if not via use.desc?" > > considering there's a ton more LINGUAS values than we have USE flags (just > run > `wc` on use.desc and lang.desc), bloating use.desc with LINGUAS settings > benefits *noone* > > we have lang.desc, it is quite populated, what's wrong with having portage > read that Absolutely nothing. I am in no way suggesting that use.desc is the possible fix. I wasn't even suggesting that each individual flag need be documented. However, if lang.desc already exists (and it does) and can be renamed to linguas.desc, it is probably a better way to manage it than use.desc. Is having INPUT_DEVICES and the like following the same scheme (ie, input_devices.desc) acceptable? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Unmasking modular X
On Wednesday 01 February 2006 02:28, Mark Loeser wrote: > Jason Stubbs <[EMAIL PROTECTED]> said: > > Is there any need for the packages to go into stable without the X deps > > being > > fixed? Why not just open a bug for the package maintainer and mark it > > against > > whatever bug is requesting stabling of that package? Moving something to > > stable that you know is going to be broken within a relatively short > > timeframe seems like a very bad idea... > > We are talking about completely unrelated versions, not what we are touching. > For example, old imagemagick ebuilds sitting around, where the newer ebuilds > are fixed, but old ones are not. We have a security bug open about this > package right now, and having an error about deps in some old version doesn't > really help arch teams at all. Security bugs are about the only time I can see any urgency. That's not a good reason to completely degrade the error though. A switch similar to --ignore-other-archs that skips certain checks for urgent fixes seems reasonable though. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
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] New developer: Jokey (Markus Ullmann)
[EMAIL PROTECTED] wrote: Hi all. Markus has been contributing to gentoo through bugzilla and bugdays for a few months and have now finally joined the ranks of official Gentoo developers. Markus is going to help with netmon related ebuilds. Markus tells us about himself: "I'm a 23 year old geek, trying to spread linux around the world ;) At the moment I live at my parents near Hamburg/Germany and I'm studying electrical engineering at University of Applied Sciences, Hamburg. I greatly enjoy watching all forms of Star Trek and Star Wars. For non-computerized balance I enjoy doing some Tae-Bo and go swimming with Friends and other LUGs taking part 'LUG in motion'." Please welcome Markus to the team. Regards, Bryan Ăstergaard LUG in Motion? H sounds interesting. Welcome aboard Markus! -- 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
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 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
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 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
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
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 your package ... is supposed to "just work" for the end-user, 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
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] Re: Unmasking modular X
On Tue, 31 Jan 2006 10:41:36 -0800 Donnie Berkholz <[EMAIL PROTECTED]> wrote: | Mark Loeser wrote: | > We are talking about completely unrelated versions, not what we are | > touching. For example, old imagemagick ebuilds sitting around, | > where the newer ebuilds are fixed, but old ones are not. We have a | > security bug open about this package right now, and having an error | > about deps in some old version doesn't really help arch teams at | > all. | | Oh, so we just screw up people using modular X on a stable system by | breaking the latest stable ebuild.. It shouldn't be a critical error. Criticals make it very hard for people to fix other legitimate issues. -- 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] Re: Unmasking modular X
Mark Loeser wrote: > Jason Stubbs <[EMAIL PROTECTED]> said: >> Is there any need for the packages to go into stable without the X deps >> being >> fixed? Why not just open a bug for the package maintainer and mark it >> against >> whatever bug is requesting stabling of that package? Moving something to >> stable that you know is going to be broken within a relatively short >> timeframe seems like a very bad idea... > > We are talking about completely unrelated versions, not what we are touching. > For example, old imagemagick ebuilds sitting around, where the newer ebuilds > are fixed, but old ones are not. We have a security bug open about this > package right now, and having an error about deps in some old version doesn't > really help arch teams at all. Oh, so we just screw up people using modular X on a stable system by breaking the latest stable ebuild.. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Unmasking modular X
Jason Stubbs <[EMAIL PROTECTED]> said: > Is there any need for the packages to go into stable without the X deps being > fixed? Why not just open a bug for the package maintainer and mark it against > whatever bug is requesting stabling of that package? Moving something to > stable that you know is going to be broken within a relatively short > timeframe seems like a very bad idea... We are talking about completely unrelated versions, not what we are touching. For example, old imagemagick ebuilds sitting around, where the newer ebuilds are fixed, but old ones are not. We have a security bug open about this package right now, and having an error about deps in some old version doesn't really help arch teams at all. I am all for getting stuff ported, but making things harder for arch teams is not the way to go about it. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpn8XThystzM.pgp Description: PGP signature
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
-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 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 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] IUSE and LINGUAS?
On Tuesday 31 January 2006 06:31, Jason Stubbs wrote: > On Monday 30 January 2006 20:54, Ciaran McCreesh wrote: > > 1. Because for things like LINGUAS, there are arbitrarily many legal > > values, and documenting them all and keeping the list up to date would > > be extremely difficult. > > "More precisely, how should they be documented if not via use.desc?" considering there's a ton more LINGUAS values than we have USE flags (just run `wc` on use.desc and lang.desc), bloating use.desc with LINGUAS settings benefits *noone* we have lang.desc, it is quite populated, what's wrong with having portage read that -mike -- gentoo-dev@gentoo.org mailing list
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
[gentoo-dev] Default Ebuild behaviour
-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] IUSE and LINGUAS?
On Tue, 31 Jan 2006 20:31:55 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | > 1. Because for things like LINGUAS, there are arbitrarily many legal | > values, and documenting them all and keeping the list up to date | > would be extremely difficult. | | "More precisely, how should they be documented if not via use.desc?" They shouldn't be. -- 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] IUSE and LINGUAS?
On Monday 30 January 2006 20:54, Ciaran McCreesh wrote: > On Mon, 30 Jan 2006 20:46:28 +0900 Jason Stubbs <[EMAIL PROTECTED]> > wrote: > | On Monday 30 January 2006 16:43, Ciaran McCreesh wrote: > | > On Mon, 30 Jan 2006 06:17:36 +0100 "Diego 'Flameeyes' Pettenò" > | > <[EMAIL PROTECTED]> wrote: > | > | Also, as repoman complain about linguas_blabla not being a valid > | > | useflags, all the linguas_* useflags should be listed in use.desc > | > > | > No, part of the point of USE_EXPAND is that they shouldn't. This is > | > a repoman bug. > | > | I have yet to be enlightened on any merit of USE_EXPAND is so perhaps > | you could explain as to why there should be > | user-configured-yet-undocumented options for ebuilds? More precisely, > | how should they be documented if not via use.desc? > > 1. Because for things like LINGUAS, there are arbitrarily many legal > values, and documenting them all and keeping the list up to date would > be extremely difficult. "More precisely, how should they be documented if not via use.desc?" > 2. Because USE_EXPAND is used for special USE things like arch and > userland, and because we undocumented the special arch USE flags > because they're not user settable. These variables are internal and not meant to be user configurable. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Unmasking modular X
On Tuesday 31 January 2006 13:49, Joshua Jackson wrote: > Mark Loeser gentoo.org> writes: > > Donnie Berkholz gentoo.org> said: > > > Jason Stubbs wrote: > > > > The patch now has the debugging output and x11-base/xorg-x11 check > > > > removed. > > > > > > Excellent. Works perfectly. Since we're failing on them, perhaps we can > > > say "obsolete" instead of "deprecated"? > > > > Can we put this back to being a warning? It makes things a pain for arch > > teams that are trying to mark a completely unrelated version of the > > package. > > I will have to agree that this change has made it a pain to mark anything > stable. I had 4 out of the 6 I did today bail out because of this. I took > the simple easy fix and removed the check to stabalize the packages I needed > to. I know we have people who want modular X yesterday, but causing trouble > for dev's going about business that doesn't involve the modular problems > directly is only going to cause resentment and frustration to all the teams > involved. Is there any need for the packages to go into stable without the X deps being fixed? Why not just open a bug for the package maintainer and mark it against whatever bug is requesting stabling of that package? Moving something to stable that you know is going to be broken within a relatively short timeframe seems like a very bad idea... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Find apps not ported to modular X
The last change: 401 up to 406. Yes, it actually got worse. This is caused by artifacts fixed by the recent portage 2.1 revision bump, because I know some apps were fixed. Progress graph: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_progress.png Latest list: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060130 Herds with 10 or more unported packages, and change in # of packages: 95 games (-0) 61 none (individual or no maintainer) (-1) 54 desktop-dock (-0) 33 (no metadata.xml) (-1) 30 desktop-wm (-0) 22 cjk (-1) 18 sci (+4) 14 video (-0) IRC: #gentoo-x Documentation: http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml Metabug: http://bugs.gentoo.org/112675 If you can't figure out what needs to get done and you've already read the docs, ask in #gentoo-x. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Unmasking modular X
Joshua Jackson wrote: > To quote one of the ebuild-quiz questions: You wish to make a change > to an ebuild, but you checked the ChangeLogs and metadata.xml and it > appears to be maintained by someone else. How should you proceed? > > A general response that is obtained from the documentation source > (either the unofficial dev guide or the developer doc's) Concerns > getting in contact with the maintainer before you make the changes. > Explaining the how and why and either asking them to take care of it > or asking for permission to do so. We've had many developers get > highly upset at another developer changing even a minor thing in their > ebuild...such as the simple changing of depends. Only two groups have mentioned anything about touching modular X deps: gnome and games. Gnome (in the form of dang) requested bugs filed, and games requested they be contacted about changes made. > this is a Relations nightmare. Not to > mention Quality Control implications it can have, something that I > think as a whole development community we've worked very hard at > improving vastly. For the relations side, see above. I'm not really seeing the quality control aspect. Can you explain to me how that works, given that all these deps have been tested in ~arch? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Unmasking modular X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: > Joshua Jackson wrote: >> In the oldest version of the package (as all these were), I don't >> see much point in the change. They will be removed within a >> fairly short amount of time. > > Fairly short meaning what, 6 months? A lot of old ebuilds tend to > stick around forever. > True, some older packages stay around longer then they probably should, and was a exageration on my part but it does prove the point that the check is somewhat superfluous for most users, since it seems that most people (from a rough estimate of 2 years on the forums) seems that 1month is about the outside for most people's updates. As the point has been brought up about packages being in there longer, it'd be interesting to write something to do a check for multiple stable versions with a older version being >=6 months old. Something I might go look into. >> Secondary, you are suggesting that any dev who comes across a >> modular x problem to fix it..even if this is a direct violation >> of the guidelines set forth in the documentation? > > Which guidelines, exactly? I'm having trouble finding these vague > guidelines to which you refer. > > I found one that said "If you make an internal, stylistic change to > the ebuild that does not change any of the installed files, then > there is no need to bump the revision number." > > I also found "When a package version has proved stable for > sufficient time and the Gentoo maintainer of the package is > confident that the upgrade will not break a regular Gentoo user's > machine, then it can be moved from ~ARCH to ARCH," which, to my > reading, can also apply to transferring ~arch modular X deps to > stable. > > Thanks, Donnie > To quote one of the ebuild-quiz questions: You wish to make a change to an ebuild, but you checked the ChangeLogs and metadata.xml and it appears to be maintained by someone else. How should you proceed? A general response that is obtained from the documentation source (either the unofficial dev guide or the developer doc's) Concerns getting in contact with the maintainer before you make the changes. Explaining the how and why and either asking them to take care of it or asking for permission to do so. We've had many developers get highly upset at another developer changing even a minor thing in their ebuild...such as the simple changing of depends. Bringing it back around to Mark's initial point, the check causes extra work for a arch developer that would require stepping on another herd/developers package's..this is a Relations nightmare. Not to mention Quality Control implications it can have, something that I think as a whole development community we've worked very hard at improving vastly. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD3x1lSENan+PfizARAqFoAJ9tAQ9UI0X3MCXG9A7DjWgrheBWfgCgnUG+ gRDzL4aW8JKoiZEcdNAPgLk= =/VRh -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
