Re: [gentoo-portage-dev] Improved user information and communication
On Sunday 02 October 2005 01:08, Daniel Stiefelmaier wrote: On Saturday 01 October 2005 14:17, Jason Stubbs wrote: This should go to [EMAIL PROTECTED] as ebuild developers are the ones that decide what USE flags are available and how they're documented. Of course they decide what flags are available, but how do they decide how they are documented? I'm sorry if i did not yet discover gentoos ebuild-feature-documentation system. I meant the actual strings themselves. However, any change that affects or enables work for ebuild devs really needs to be discussed with them. I thought of a command like emerge mozilla-firefox --useinfo that prints what each flag is good for. Maybe some are explained in 5 words, other may need 5 lines. Personally, I think that this has only become necessary because USE flags are overloaded too much and usually encompass an unintuitive set of functionality. In other words, I think the flaw is with the USE flags that have been created rather than the USE system itself. Take the USE flag perl, for example. It has the description Adds support/bindings for the Perl language. but for mysql setting it enables the installation of some support scripts that just happen to be written in perl. I'd be much more inclined to push for making the USE flags themselves more intuitive rather than adding another layer of documentation to exlain the unintuitiveness (which would likely be poorly written anyway). also, the advanced could provide - links to howto's (like configuring apache) This is out of the domain of a package in any package management system IMO. You are right, there may be no pms out there that has this feature. I refuse to accept this as an argument to not change that. You may be a pro who does not need any HOWTOs, i am not. HOWTOs can usually be found by navigating from the package's home page. If not, a quick google will find any that exist. Portage saves a lot of work for people who use it. But in some cases, ebuilds don't do everything they could or should. If ebuilds aren't doing what they could or should be, you can open specific bugs regarding those packages. BTW, if This is out of the domain of a package in any package management system, then why do some packages print additional information after emerging, like what files should be updated manually? Usually it's because configuration file layout differs from upstream's defaults or some other Gentoo-specific information. THIS is not really the solution. if you batch-emerge or the package that wants to tell you something is just a dependancy, then you may probably miss that note. http://bugs.gentoo.org/show_bug.cgi?id=11359 Another reason to inform the user before emerging maybe this: I emerged a package recently, think it was amule, that first emerged some dependancies, including wxGTK. Then, after all dependancies were emerged, the package itself quitted saying that wxGTK needs to be emerged with flag wxgtk1. I thought the ebuild could manage flags of dependancies automatically, but that is not the point. The user could be informed before starting to emerge. http://bugs.gentoo.org/show_bug.cgi?id=2272 - list packages that are of use for this (plugins or utilized apps like cervisia that integrates in quanta plus) Do you mean finding packages that depend on that package in question? Not necessarily. Cervisia, Kompare and Tidy are standalone applications, but Quanta integrates them automatically if they are installed. A related field? Could be useful. This is also a point for discussion on [EMAIL PROTECTED] though. Personally, I hate most wikis. 9 times out of 10, they are full of half-correct information. This makes them all the more dangerous as the average Joe can't tell what's correct and what isn't. My wiki experiences are all good, but i also wrote, that it could only be maintained by the developers. Only the discussion page attached to each page is open for comments. This also prevents defacements. More work for ebuild devs, then. Guess where this discussion should be? ;) -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Improved user information and communication
I thought of a command like emerge mozilla-firefox --useinfo that prints what each flag is good for. Maybe some are explained in 5 words, other may need 5 lines. Personally, I think that this has only become necessary because USE flags are overloaded too much and usually encompass an unintuitive set of functionality. In other words, I think the flaw is with the USE flags that have been created rather than the USE system itself. Take the USE flag perl, for example. It has the description Adds support/bindings for the Perl language. but for mysql setting it enables the installation of some support scripts that just happen to be written in perl. I'd be much more inclined to push for making the USE flags themselves more intuitive rather than adding another layer of documentation to exlain the unintuitiveness (which would likely be poorly written anyway). You say it has become necessary... wow... If you think a special flag has a bad name, just tell the ebuild maintainers to rename it. They will do. Sure. Just as i always get positve feedback when i make a request for enhancement... Renaming would cause new trouble, i guess you know that better than me. But even if your flag was named usefulperlplugins it would not say all that could be said about it. When you told me about --changelog i just wondered you didn't tell me to rtfm. man emerge provides information on possible options, why should there not be a way to get information on an ebuilds option??? The useflag xprint sounds like printing support, but doesn't tell if you need it if you use cups or the kde-printing system or... whatever. HOWTOs can usually be found by navigating from the package's home page. If not, a quick google will find any that exist. - There are many Gentoo-related HOWTOs, not linked on a projects homepage - Some ebuilds give homepages like gnome.org just for some little gnome app that is not linked on gnome.org - There are not only howtos but other useful related pages Maybe 9000 ebuilds will never have HOWTOs linked to them and maybe 50% of the users will never use the advanced information. But the others will. Why do you think just because YOU don't need it, noone will? No, don't give information to users! Don't have a defined way to get information to a package! It's evil! The defined way would be wiki-URL/ebuild or emerge ebuild --help or whatever. You don't want anything like that and i don't understand that. BTW, if This is out of the domain of a package in any package management system, then why do some packages print additional information after emerging, like what files should be updated manually? Usually it's because configuration file layout differs from upstream's defaults or some other Gentoo-specific information. That question was rhetorical. Of course it's because portage can't handle everything. This is why there should be an easy, defined way to get information. Caliga -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Improved user information and communication
Hi, Daniel Stiefelmaier wrote: Take the USE flag perl, for example. It has the description Adds support/bindings for the Perl language. but for mysql setting it enables the installation of some support scripts that just happen to be written in perl. Since perl is a global use flag, this is inappropriate use. You might want to file a bug :) man emerge provides information on possible options, why should there not be a way to get information on an ebuilds option??? because emerge is the tool, not the object. You wouldn't expect the openoffice documentation to cover examples for different kinds of letters, would you? The useflag xprint sounds like printing support, but doesn't tell if you need it if you use cups or the kde-printing system or... whatever. ~ $ grep xprint /usr/portage/profiles/use.desc xprint - Support for xprint, http://www.mozilla.org/projects/xprint/ what do you need more? - There are many Gentoo-related HOWTOs, not linked on a projects homepage You can easily find those through searching google - Some ebuilds give homepages like gnome.org just for some little gnome app that is not linked on gnome.org Same here, googling usually helps - There are not only howtos but other useful related pages Same here. Why do you think just because YOU don't need it, noone will? This is not a personal debate. The most important reason I see against this idea is that portage is a package manager, not a documentation center. Why should the ebuild contain links to documentation? To be honest, not even the HOMEPAGE info is needed, it's just for the user's convenience. I tend to refer to the UNIX principle: The right tool for the right job. For your problem, google (or any other search engine of course) is the right tool. No, don't give information to users! Don't have a defined way to get information to a package! It's evil! Do you think we're all sadists? Sorry, but such statements don't help your argumentation. BTW, if This is out of the domain of a package in any package management system, then why do some packages print additional information after emerging, like what files should be updated manually? For the user's convenience of course. Introducing documentation links in ebuilds however is a massive effort, and I don't think that effort is worth it. I'd rather fix a broken package than googling for documentation. I'm sure every user is able to search for HOWTOs, but not every user is able to fix a broken package himself. That question was rhetorical. Of course it's because portage can't handle everything. This is why there should be an easy, defined way to get information. This defined way is google, IMHO. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Improved user information and communication
man emerge provides information on possible options, why should there not be a way to get information on an ebuilds option??? because emerge is the tool, not the object. You wouldn't expect the openoffice documentation to cover examples for different kinds of letters, would you? err.. i think you got me wrong... i do not expect emerge to have a built-in list of use flags. The description should be in the .ebuilds or metadata.xml But i hope you do agree, that eix or emerge are the appropriate tools to dig such information. (maybe eix more than emerge) Just like emerge -vv will print information about the ebuild maintainers in future release, if i got that right. The useflag xprint sounds like printing support, but doesn't tell if you need it if you use cups or the kde-printing system or... whatever. ~ $ grep xprint /usr/portage/profiles/use.desc xprint - Support for xprint, http://www.mozilla.org/projects/xprint/ what do you need more? - ease of use - elegance - not need to know about every portage file (especially if new to gentoo) - time efficiency (for dozens of flags) - non-global flags eix also provides only information that you could grep in a more or less elegant way. or using google... Why do you think just because YOU don't need it, noone will? This is not a personal debate. The most important reason I see against this idea is that portage is a package manager, not a documentation center. most programs, even those for gurus, print information about their option or AT LEAST how to GET information. still, these programs are not a documentation center. Why should the ebuild contain links to documentation? To be honest, not even the HOMEPAGE info is needed, it's just for the user's convenience. even emerge is just for the user's convenience even distributions are just for the user's convenience, who needs them? i never heard someone argueing that a feature is needless because it is convenient. features are there to be convenient. I tend to refer to the UNIX principle: The right tool for the right job. For your problem, google (or any other search engine of course) is the right tool. what should i say? don't you have bookmarks of good sites? do you always google for them? of course you will get what you want in many cases but not always. another unix principle is that everybody can do everything the way he likes. in this case, i prefer to have a readers choice instead of googling and digging the perls. also, i agree that emerge may not be the right tool for that. may be eix or a new one. what this is about, is including additional information (only one link that will not hurt you) in the ebuilds or metadata.xml Do you think we're all sadists? No, but hard to believe that you are not ignorant against people - that like to have features you personally find useless - that may be not using linux since 1992 and need more good documentation to install and maintain their system - that (therefore) do not know the linux/gentoo/portage file structure by heart Sorry, but such statements don't help your argumentation. Did you think the statements in Jasons first reply were all helping the discussion? BTW, if This is out of the domain of a package in any package management system, then why do some packages print additional information after emerging, like what files should be updated manually? For the user's convenience of course. This sounds like they are needless. Introducing documentation links in ebuilds however is a massive effort, and I don't think that effort is worth it. I'd rather fix a broken package than googling for documentation. I did not yet dive into portage, but why is it such a big effort? For the ebuilds themselves it is adding one more line on the next regular update. (This would be for the wiki. If the help on the useflags would be included in the ebuild and not in the wiki, yes, then it would be a bit more effort. But i guess the maintainers know their flags and could add some lines that describe them quickly) That question was rhetorical. Of course it's because portage can't handle everything. This is why there should be an easy, defined way to get information. This defined way is google, IMHO. IMHO it is a helpshift Caliga -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Improved user information and communication
On Sat, Oct 01, 2005 at 11:57:01PM +0200, Daniel Stiefelmaier wrote: man emerge provides information on possible options, why should there not be a way to get information on an ebuilds option??? because emerge is the tool, not the object. You wouldn't expect the openoffice documentation to cover examples for different kinds of letters, would you? err.. i think you got me wrong... i do not expect emerge to have a built-in list of use flags. The description should be in the .ebuilds or metadata.xml But i hope you do agree, that eix or emerge are the appropriate tools to dig such information. Nope, I don't agree. (maybe eix more than emerge) Just like emerge -vv will print information about the ebuild maintainers in future release, if i got that right. Lifted from metadata.xml . Jamming a 'built-in list of use flags' into ebuilds/metadata.xml first of all is vague, second of all is going to jack up the tree's size, third of all will lead to a buttload of redundant information across the tree. So... nail it down, instead of the vague eix/emerge should do this. If you're suggesting it read use.* info from profiles/use.*, state so. The useflag xprint sounds like printing support, but doesn't tell if you need it if you use cups or the kde-printing system or... whatever. ~ $ grep xprint /usr/portage/profiles/use.desc xprint - Support for xprint, http://www.mozilla.org/projects/xprint/ what do you need more? - ease of use - elegance Eye of the beholder, not an objective point - not need to know about every portage file (especially if new to gentoo) - time efficiency (for dozens of flags) for x in flag1 flag2 flag3; do grep /usr/portage/profiles/use.*; done - non-global flags See above. eix also provides only information that you could grep in a more or less elegant way. or using google... Portage does you mean, since eix is just a tool that read directly from portage underlying files (and is going to get boned by portage changes to the underlying cache at some point). Use ufed, is my opinion on this, or write a tool/extension of existing tools. Why do you think just because YOU don't need it, noone will? This is not a personal debate. The most important reason I see against this idea is that portage is a package manager, not a documentation center. What you're not groking here is that people work on A) what they find interesting B) what they think *needs* to be done. Via that ordering, the subjective bit you're throwing out is nulled; use flag display is minor compared to fixing portage's screwups from where I sit. Additionally turning the question, Why do you think just because YOU think it's needed, others will? most programs, even those for gurus, print information about their option or AT LEAST how to GET information. still, these programs are not a documentation center. This makes no sense. Why should the ebuild contain links to documentation? To be honest, not even the HOMEPAGE info is needed, it's just for the user's convenience. even emerge is just for the user's convenience even distributions are just for the user's convenience, who needs them? i never heard someone argueing that a feature is needless because it is convenient. features are there to be convenient. Stretching the example to the extreme doesn't prove your point (don't do it if you want people to actually respond). I tend to refer to the UNIX principle: The right tool for the right job. For your problem, google (or any other search engine of course) is the right tool. what should i say? don't you have bookmarks of good sites? do you always google for them? of course you will get what you want in many cases but not always. another unix principle is that everybody can do everything the way he likes. in this case, i prefer to have a readers choice instead of googling and digging the perls. You've got the unix principle slightly wrong there- implicit is that if no alternative exists, the person persuing the alternative *implements* it themselves rather then riding others to do it. also, i agree that emerge may not be the right tool for that. may be eix or a new one. what this is about, is including additional information (only one link that will not hurt you) in the ebuilds or metadata.xml Guessing you're not aware of the cache, nor the dtd for metadata.xml Slapping stuff into the cache requires portage modifications, both for the package and for the rsync cache generation. It can be done, but the question before doing it is exactly what this is going to yield, is it really the right route, and what is going to be broken by this (since tools *do* read directly from cache entries even if it's daft to do so). Do you think we're all sadists? No, but hard to believe that you are not ignorant against people - that like to have features you personally find useless - that may be not using linux since
Re: [gentoo-portage-dev] Improved user information and communication
Jamming a 'built-in list of use flags' into ebuilds/metadata.xml first of all is vague, I tried to explain simon that i don't want to have the explanations built into the emerge-programm, because i thought he understood me that way. second of all is going to jack up the tree's size, i dont believe that as i'd guess only the most common ebuilds would have it added in the near future. also it seems to me that the changelog files take way the most place. I already said, that it might be satisfying to only include a wiki-link. A new tool, lets say einfo, that prints info from metadata.xml. The link could be read from metadata.xml or, if desired, generated automatiacally in the form http://gentoo-wiki.com/Ebuild:www-client/mozilla-firefox; third of all will lead to a buttload of redundant information across the tree. global use flag definitions could still be used, but optionally overwritten with local ones in the ebuilds. So... nail it down, instead of the vague eix/emerge should do this. im getting vague because if i am precise, everybody just tells me that it will not work that way. i did not yet get constructive feedback and i don't know portage and its developers well enough to make a pleasing plan. If you're suggesting it read use.* info from profiles/use.*, state so. To be honest i just discovered use.local.desc, i didn't know this already exists. (only use.desc) Sorry for my lack of knowledge. Constructive feedback would have been to tell me the information i want already exists. Nobody wondered, why i want to add information to ebuilds that already exists. Well, that's fine. :) Just that some flags could be explained more comprehensive, not only telling the obvious. Now i understand Jason and agree, that missused global flags should be renamed. (but still believe there is a small chance they will) Use ufed, is my opinion on this, or write a tool/extension of existing tools. Now that i know that all the needed metadata already exists, i can :) You've got the unix principle slightly wrong there- implicit is that if no alternative exists, the person persuing the alternative *implements* it themselves rather then riding others to do it. all the responses i got were so declining that i thought even if you would code it, we will never include it, even if you'll edit all the 10k metadata.xml files, we just don't WANT it, it's useless for us and everybody else wrong conclusion? You're not convincing anybody that *your* personal opinion of how it should be done is the correct way, it wasn't on my mind to say *how* it should be done. but all replies just were saying it should be done at all, it's useless, senseless, to much work... that off if you're being agressive/insulting about it (I'll give you the benfit of the doubt and assume you're not intentionally trying to insult people). Thanks. I'd say it was more of a desperate sigh. Sarcastic i have to admit. ;) Additionally... you're proposing a retrofit of metadata into the entire tree, which is a *lot* of work (that's fact), leaving the question of what really is gained, if there was a better way, etc. I expected to hear the better way from the experienced. Maybe you are the one who finally pointed me to it, indirectly :) greets, Caliga -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Improved user information and communication
On Saturday 01 October 2005 14:01, Daniel Stiefelmaier wrote: I'd like to introduce two ideas i had to improve portage. I haven't had an idea introduced to me that was new for at least a year.. Patches are more interesting. sometimes i'd like to know something more about a package before i emerge it. 1. release notes. (for the ebuild, not the application) as a release notes file exists, a parameter could be used to show the most recent entry. maybe this fits eix better than emerge emerge --changelog ? 2. advanced package info most important here is an explanation of the available use flags. i know there is a list of most flags (http://www.gentoo.org/dyn/use-index.xml) but it is incomplete and doesnt explain some flags well. some have different behaviour in different packages. some flags are self-explanatory, but some are not. for example, the xprint comment should say, that this is not necessary to print, and under what circumstances it is needed. This should go to [EMAIL PROTECTED] as ebuild developers are the ones that decide what USE flags are available and how they're documented. also, the advanced could provide - links to howto's (like configuring apache) This is out of the domain of a package in any package management system IMO. - list packages that are of use for this (plugins or utilized apps like cervisia that integrates in quanta plus) Do you mean finding packages that depend on that package in question? - tell how to contact the ebuild maintainer metadata.xml. This information is printed out when using -vv in portage-2.1_alpha. that led my to another idea: a wiki for all ebuilds in portage. all the information could then be in the wiki, and eix/emerge just print the wiki-link. i'd suggest mediawiki, as it has a discussion page attached. maybe the wiki itself can only be changed by developers, and feedback is given on the discussion page. Personally, I hate most wikis. 9 times out of 10, they are full of half-correct information. This makes them all the more dangerous as the average Joe can't tell what's correct and what isn't. just some ideas, maybe needing some development, i hope you find them useful. :) Ideas are a dime, a dozen. -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
