Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[New package] emod, easily edit your use flags
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
apinsard
n00b
n00b


Joined: 24 Mar 2012
Posts: 74
Location: France

PostPosted: Thu Feb 14, 2013 6:02 am    Post subject: [New package] emod, easily edit your use flags Reply with quote

Hi,

I might be a bit absent-minded but I sometimes forget a ">" when running "echo dev-utils/example sample flag -test >> /etc/portage/package.use".

Fortunately I have backups but this is nevertheless not very convenient.

I looked for a tool that could do it for me but I didn't find anything. So I decided to develop my own.

I think I'm not the only one to have this problem, and anyway, this tool also enables to edit existing "flags" of a particular ebuild and sorts them in alphabetical order. So I decided to submit it. This is also for me the chance to have a first experience with Gentoo packaging.

I am currently writting the ebuild, but before submitting my tool, I would like to make sure such a tool doesn't already exist.

I also would like to get feedbacks on my script.

  • Features that could be good to add
  • Parts of the code that need more comments
  • English mistakes in comments? (I'm french and my english is not as good as I would like) I might have not used the right terms as well.
  • Code optimisation


Here it is: https://github.com/Pyntony/emod/blob/master/emod

Thanks.

Edit 05/12/2013: Changed git repository.
Edit 02/16/2013: Delete the old code block and replaced by a link to the new source.


Last edited by apinsard on Sun May 12, 2013 10:58 am; edited 2 times in total
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Thu Feb 14, 2013 8:29 am    Post subject: Reply with quote

Features good to add?

Everything the "euse" utility does, but adding the handling of /etc/portage/package.use.

Maybe rather than write a new tool, you could update that one. Also take out nonsense about local vs global USE flags, which doesn't really matter any more.
_________________
patrix_neo wrote:
The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2280
Location: Adendorf, Germany

PostPosted: Thu Feb 14, 2013 8:55 am    Post subject: Reply with quote

If it is just about not accidently erasing your package.use file, something like this should do:
Code:
#!/bin/bash

tgt=/etc/portage/package.use

if [ $# -lt 2 ] ; then
        echo "Usage:"
        echo "  $0 <package> <use flag> [other use flags]"
        exit 1
fi

echo "$@" >> ${tgt}
Actually this is what I am using.
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
apinsard
n00b
n00b


Joined: 24 Mar 2012
Posts: 74
Location: France

PostPosted: Thu Feb 14, 2013 10:46 am    Post subject: Reply with quote

Yamakuzure, that's right, this should do the job. But now that the tool is developed (and more efficient), why not using it.

BoneKracker, that's a good idea. This will also help me with my first steps on Portage packaging as the ebuild is already written.

But I need to have the very latest version of euse, how can I find it? And how can I be sure that a new version is not in development ?

Edit. I just realized euse was written in bash. Which is a bit unmaintainable for a 1300 lines file. I think I can rewrite it in python and add support of local flags and package.{keywords,accept_keywords,mask,unmask,license} as well.

I juste have a few questions to make it more accurate:

Does mask, unmask accept flags after the ebuild atom?
And what's the difference between package.keywords and package.accept_keywords?
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2280
Location: Adendorf, Germany

PostPosted: Thu Feb 14, 2013 1:15 pm    Post subject: Reply with quote

apinsard wrote:
I juste have a few questions to make it more accurate:

Does mask, unmask accept flags after the ebuild atom?
And what's the difference between package.keywords and package.accept_keywords?
First of all you might want to read "man portage". All those files are explained in there.

Now the first: To mask/unmask flags you need to edit /etc/portage/package.use.mask - There flags are accepted.

For the second: package.keywords is the place you want. You can use package.accept_keywords to accept keywords from other systems. Like you are on amd64 and want a package that is only available for x86, then you *could* add "foo/bar x86" to package.accept_keywords.
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
apinsard
n00b
n00b


Joined: 24 Mar 2012
Posts: 74
Location: France

PostPosted: Fri Feb 15, 2013 10:54 am    Post subject: Reply with quote

Thank you.

I will improve my script before submitting it. However, I don't think rewritting euse is a good idea eventually. Supporting backward compatibility could be a bit difficult and it means to fully understand euse.
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Sat Feb 16, 2013 12:37 am    Post subject: Reply with quote

I disagree. I think attempting to replace an aging tool that's becoming obsolete with something more functional and faster is preferable to adding yet another narrowly-useful portage-related utility to the pile of others, where it will probably be ignored.
_________________
patrix_neo wrote:
The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Feb 16, 2013 1:59 am    Post subject: Reply with quote

apinsard wrote:
Yamakuzure, that's right, this should do the job. But now that the tool is developed (and more efficient), why not using it.

So his/her tiny scriptlet does the job, but is less efficient than loading the python interpreter? I'd have to disagree.

In fact his (forgive me if you're female, Yamakuzure) script is entirely compatible with POSIX sh, and would work in busybox, ie with #!/bin/bb as its first line which would make it even more efficient and quick. It'd be perfectly simple to extend it as well, and could be used in rescue situations, or an initramfs, which a python script cannot (it requires /usr and a whole host of libraries.)

You asked in your first post whether any similar tools exist. If you bear in mind that you normally want to change USE flags when doing an emerge -p, then update allows you to edit USE flags for any package or globally, from a dialog, and it changes flags along with portage recommendations automatically, once you confirm that's what you want to do.

By all means go ahead and work on whatever interests you in whatever language you want, but with respect to a simple clean tool just to do this one job, please consider collaborating with Yamakuzure, or extend his script under busybox if s/he's not interested. That would be of interest (and utility) to many more people, including embedded users compiling for Android or Raspberry Pi.

If you're new to sh the language is described here and the portable utilities here. You can get help learning it in #bash on IRC chat.freenode.net so long as you specify that you are writing sh upfront. Also, we hang out in #friendly-coders and you can always ask us for advice too, or explanations of what the #bash people have said.

Yamakuzure you can also change: $0 to ${0##*/} to make the program name look nicer. It'll get rid of any leading folder part, including ./ when testing, or when someone copies it to eg: /bin/adduse or /usr/bin/adduse.
Back to top
View user's profile Send private message
apinsard
n00b
n00b


Joined: 24 Mar 2012
Posts: 74
Location: France

PostPosted: Sat Feb 16, 2013 8:47 am    Post subject: Reply with quote

steveL wrote:
apinsard wrote:
Yamakuzure, that's right, this should do the job. But now that the tool is developed (and more efficient), why not using it.

So his/her tiny scriptlet does the job, but is less efficient than loading the python interpreter? I'd have to disagree.

Sorry, "efficient" was probably not what I meant to say. I wanted to say that though his script obviously does the job, mine provides more features. Such as editing an existing line.

steveL wrote:
In fact his (forgive me if you're female, Yamakuzure) script is entirely compatible with POSIX sh, and would work in busybox, ie with #!/bin/bb as its first line which would make it even more efficient and quick. It'd be perfectly simple to extend it as well, and could be used in rescue situations, or an initramfs, which a python script cannot (it requires /usr and a whole host of libraries.)

Thank you for pointing this out. I didn't thought about it.

steveL wrote:
You asked in your first post whether any similar tools exist. If you bear in mind that you normally want to change USE flags when doing an emerge -p, then update allows you to edit USE flags for any package or globally, from a dialog, and it changes flags along with portage recommendations automatically, once you confirm that's what you want to do.

Hmm, never noticed this feature, I will check it out.

steveL wrote:
By all means go ahead and work on whatever interests you in whatever language you want, but with respect to a simple clean tool just to do this one job, please consider collaborating with Yamakuzure, or extend his script under busybox if s/he's not interested. That would be of interest (and utility) to many more people, including embedded users compiling for Android or Raspberry Pi.

Sorry if I didn't make myself clear, but I don't reject his script at all. I think both scripts can live together on different purposes.

steveL wrote:
If you're new to sh the language is described here and the portable utilities here. You can get help learning it in #bash on IRC chat.freenode.net so long as you specify that you are writing sh upfront. Also, we hang out in #friendly-coders and you can always ask us for advice too, or explanations of what the #bash people have said.

You probably refer to this : " I just realized euse was written in bash. Which is a bit unmaintainable for a 1300 lines file."
Actually, I already have a few years of practice with bash and csh. However I'm an advocate of those who think a shell script mustn't do more than about 50 lines. After what, it becomes pretty unreadable and unsustainable.

BoneKracker wrote:
I disagree. I think attempting to replace an aging tool that's becoming obsolete with something more functional and faster is preferable to adding yet another narrowly-useful portage-related utility to the pile of others, where it will probably be ignored.

Hmm, do you think backward compatibility is essential for this tool ? Some of the features are not actually documented and I don't think global useflags edition through euse has an actual interest nowadays.

PS: Here is the new source https://github.com/Pyntony/funtoo/blob/master/emod
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Sat Feb 16, 2013 9:22 am    Post subject: Reply with quote

No, I don't think backward compatibility is essential. However, I think it's probably more likely to be perceived as a replacement for euse (and if it's good, possibly incorporated into gentoolkit in its place) if it seems to the user like somewhat like a drop-in replacement.

You might want to get some advice from some portage-savvy devs and/or users on what to keep and what to dispose of (e.g., I don't think the distinction between local and global use flags is important to users any longer, but being able to check and modify flags on a per-package basis (in package.use) would be a useful addition, as would the ability to remove entries for packages no longer installed and remove flags that packages no longer have.

This is just one guy's opinion here. :)
_________________
patrix_neo wrote:
The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.
Back to top
View user's profile Send private message
apinsard
n00b
n00b


Joined: 24 Mar 2012
Posts: 74
Location: France

PostPosted: Sat Feb 16, 2013 11:03 am    Post subject: Reply with quote

Indeed, it would be great to get developers feedbacks and advises. Do you know where I can get some ?
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Sun Feb 17, 2013 12:55 am    Post subject: Reply with quote

I think you can figure that out if you've read through all the Gentoo documentation.
_________________
patrix_neo wrote:
The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.
Back to top
View user's profile Send private message
smartass
Apprentice
Apprentice


Joined: 04 Jul 2011
Posts: 189
Location: right behind you ... (you did turn around, didn't you?)

PostPosted: Sun Feb 17, 2013 6:01 am    Post subject: Reply with quote

I'm sorry to discourage you, but you're just reinventing the wheel.
There are several tools for this (euse, flaggie). Rather than trying to figure out on your own how to do some stuff, why don't you put your skills to work on improving the existing tools?
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Sun Feb 17, 2013 6:38 am    Post subject: Reply with quote

What's "flaggie"?
_________________
patrix_neo wrote:
The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.
Back to top
View user's profile Send private message
apinsard
n00b
n00b


Joined: 24 Mar 2012
Posts: 74
Location: France

PostPosted: Sun Feb 17, 2013 10:33 am    Post subject: Reply with quote

smartass wrote:
I'm sorry to discourage you, but you're just reinventing the wheel.

This would not be a discouragement.

smartass wrote:
There are several tools for this (euse, flaggie).

euse is only for global flags. And flaggie...

Code:
$ man flaggie
No manual entry for flaggie
$ flaggie -h
At argv[1]='-h': h seems to be an incorrect global flag
Traceback (most recent call last):
  File "/usr/bin/flaggie-2.7", line 25, in <module>
    sys.exit(main(sys.argv))
  File "/usr/lib64/python2.7/site-packages/flaggie/cli.py", line 202, in main
    mkconf.write()
  File "/usr/lib64/python2.7/site-packages/flaggie/makeconf.py", line 644, in write
    f.write()
  File "/usr/lib64/python2.7/site-packages/flaggie/packagefile.py", line 174, in write
    dir = os.path.dirname(os.path.realpath(self.path)))
  File "/usr/lib64/python2.7/tempfile.py", line 454, in NamedTemporaryFile
    (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags)
  File "/usr/lib64/python2.7/tempfile.py", line 235, in _mkstemp_inner
    fd = _os.open(file, flags, 0600)
OSError: [Errno 13] Permission denied: '/etc/tmpMQKzxF'


smartass wrote:
Rather than trying to figure out on your own how to do some stuff, why don't you put your skills to work on improving the existing tools?

That's exactly what we are discussing. However, working on flaggie might be better than rewritting euse. I will see.

BoneKracker, actually I read parts of many documents, such as http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml But I can't figure out where to find that information.
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Sun Feb 17, 2013 11:32 am    Post subject: Reply with quote

I know. Portage is a moving target because it's constantly under development. Programmers don't like to write documentation. I haven't looked at the portage documentation pages on the web site or in the wiki(s) lately, but I suspect that the man pages for portage and emerge are about the only things reasonably current. I would recommend studying those thoroughly.
_________________
patrix_neo wrote:
The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.
Back to top
View user's profile Send private message
sera
Retired Dev
Retired Dev


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Sun Feb 17, 2013 12:23 pm    Post subject: Reply with quote

Yamakuzure wrote:
For the second: package.keywords is the place you want. You can use package.accept_keywords to accept keywords from other systems. Like you are on amd64 and want a package that is only available for x86, then you *could* add "foo/bar x86" to package.accept_keywords.


package.accept_keywords is the new package.keywords. Settings in the former override the ones in the latter if both files are present. A tool will have to handle both locations.

Edit: Fix quoting


Last edited by sera on Sun Feb 17, 2013 12:38 pm; edited 1 time in total
Back to top
View user's profile Send private message
sera
Retired Dev
Retired Dev


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Sun Feb 17, 2013 12:37 pm    Post subject: Reply with quote

BoneKracker wrote:
I don't think the distinction between local and global use flags is important to users any longer,


There is no reason to make a distinction between global and local useflags as a user. The only difference is where developers put the useflag description.

Personally I don't like the Handbook making this distinction as it serves no purpose and may only confuse users. The other one I always trip is when reading the handbook talks about Portage Snapshot. I use Gentoo for a decade but that term still triggers the association "A vcs checkout of the software Portage" and not a tarred up tree. Just call it "package repository" and every Linux user out there will know what it is about.
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Sun Feb 17, 2013 12:59 pm    Post subject: Reply with quote

I don't know how they're actually being managed (with respect to global vs. local), but in my opinion, USE flags which have essentially the same meaning across all packages should be considered "global", while those which have substantially different effects on different packages should be considered "local".

Those classifications of "global" and "local" (which are handled well by 'euse'), should be seen by users as merely a hint that they might want to lean toward applying a given flag in make.conf (i.e. universally) or in package.use (i.e. selectively).

People should stay away from using the terms "globally" to describe the effect of USE flags in make.conf or the term "locally" to describe the effect of USE flags in package.use because this confuses people.

Also, while most of them are lucid, some USE flag descriptions could be a little more explicit than "enable support for foo". :lol:

Recent additions to /etc/portage could be more extensively documented (per-package CFLAGS and envvars, for example, which many people are doing differently).
_________________
patrix_neo wrote:
The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9501
Location: beyond the rim

PostPosted: Wed Feb 20, 2013 11:11 am    Post subject: Reply with quote

Ignore euse.
It was written a long time ago as a replacement for an even more ancient tool. Back then portage didn't really have a usable python API, that's why it was written in bash (with the editing hack attached later). Also most of the things a new version would have to care about now didn't exist (USE_EXPAND, masking/forcing flags, metadata.xml descriptions, default IUSE, ...). And the original distinction of global/local USE flags doesn't really apply anymore these days.
Back to top
View user's profile Send private message
apinsard
n00b
n00b


Joined: 24 Mar 2012
Posts: 74
Location: France

PostPosted: Wed Feb 20, 2013 2:20 pm    Post subject: Reply with quote

My tool is rather meant to deal with /etc/portage/package.* than with /etc/portage/make.conf. I think a tool to manage /etc/portage/make.conf is not that useful as you basically configure your make.conf when you first install your system and then only once in a while.

On the other hand you may have to deal with package.* each time you install a new package or reinstall one. The goal of emod is roughly to make package.* edition faster (avoiding to edit the file manually, find the right line and edit it).

I made many changes since my original post. The tool is now mainly ended. I still have to test it and write the man page. I wonder about renaming it "eflag" which might be clearer?
Back to top
View user's profile Send private message
sera
Retired Dev
Retired Dev


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Wed Feb 20, 2013 4:00 pm    Post subject: Reply with quote

BoneKracker wrote:
I don't know how they're actually being managed (with respect to global vs. local), but in my opinion, USE flags which have essentially the same meaning across all packages should be considered "global", while those which have substantially different effects on different packages should be considered "local".

The available use flags are defined in ebuilds. Eclasses and profiles can inject more. Use flags are arbitrary strings and mapped to arbitrary actions, options, dependencies and more. The wiring up is done in the ebuild, eclasses and sometimes the package manager. For all our sanity we try to use meaningful names for use flags and try to reuse the same name to mean the same across packages and try to retain the meaning over time. But that only works so well.

So in between the use flag name and reading the ebuild and the packages build system there are use flag descriptions which are put into the metadata.xml in the package directory alongside the ebuild. As use flag names may be reused across packages it only makes sense to also share a description from time to time. So if a use flag isn't described in metadata.xml a tool falls back to read a default description from profiles/use.desc for the given package and version.

And before I hear "but there is profiles/use.local.desc", that file is obsolete for many years.

BoneKracker wrote:
Those classifications of "global" and "local" (which are handled well by 'euse'), should be seen by users as merely a hint that they might want to lean toward applying a given flag in make.conf (i.e. universally) or in package.use (i.e. selectively).

I wouldn't put any use flags into make.conf. Portage supports wildcards in package.use for a while. Ie.
Code:
*/* X alsa ssl cups
sys-devel/gcc fortran

First the wildcards better expresses our intention and second there is no longer the need to move flags from file to file on arbitrary ground.

BoneKracker wrote:
Also, while most of them are lucid, some USE flag descriptions could be a little more explicit than "enable support for foo". :lol:

Can't but agree here. Horrible. :lol:
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia

PostPosted: Wed Feb 20, 2013 4:37 pm    Post subject: Reply with quote

sera wrote:
BoneKracker wrote:
Also, while most of them are lucid, some USE flag descriptions could be a little more explicit than "enable support for foo". :lol:

Can't but agree here. Horrible. :lol:
My cut on this from several years ago.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Feb 20, 2013 11:08 pm    Post subject: Reply with quote

apinsard wrote:
Sorry, "efficient" was probably not what I meant to say. I wanted to say that though his script obviously does the job, mine provides more features. Such as editing an existing line.

That's what I meant by extending it. update has always allowed editing of existing lines (in fact it shows you a coloured diff of the affected files before proceeding) so it's not like it's an unsolved problem.

Since it is so simple, and it's obvious what it does just by reading it, it's easy to extend, so long as it's crafted over time. By "crafted" I mean new features are added, slimmed-down and rewritten with knowledge of the current "not-quite" solution.

Far too many people learning nowadays, never have to revert and reimplement a whole "module" while keeping it working: it's too easy to say "here's a new version, and forget what the old one did, cos we had an idea and cba to keep your scripts working."
Quote:
Quote:
By all means go ahead and work on whatever interests you in whatever language you want, but with respect to a simple clean tool just to do this one job, please consider collaborating with Yamakuzure, or extend his script under busybox if s/he's not interested.

Sorry if I didn't make myself clear, but I don't reject his script at all. I think both scripts can live together on different purposes.

Oh I know: and I'm not telling you what to spend your time on. Just that wrt this job, your approach has fundamental drawbacks for the use-cases where a lightweight euse replacement would be of interest to end-users. It's in the wrong language for anyone who needs it to work from a rescue situation. As I said, a POSIX sh script "would be of interest (and utility) to many more people, including embedded users compiling for Android or Raspberry Pi."

Quote:
Quote:
If you're new to sh the language is described here and the portable utilities here. You can get help learning it in #bash on IRC chat.freenode.net so long as you specify that you are writing sh upfront. Also, we hang out in #friendly-coders and you can always ask us for advice too, or explanations of what the #bash people have said.

You probably refer to this : " I just realized euse was written in bash. Which is a bit unmaintainable for a 1300 lines file."

No I referred to the fact that you don't appear to know POSIX sh, and did not consider it as an implementation language. Hence "If you're new to sh"; I never mentioned bash, except to say that #bash the IRC channel are perfectly happy to discuss sh scripting as well.
Quote:
Actually, I already have a few years of practice with bash and csh. However I'm an advocate of those who think a shell script mustn't do more than about 50 lines. After what, it becomes pretty unreadable and unsustainable.

Yes, but his sh is much more readable than your python. while read -r line; do .. ; done < "$file" is a lot more transparent than your faffing about with os file opening and lambdas(!).

And csh is crap. Nor is bash the place to learn POSIX sh. If you're interested to see what's portable, read the links ('local' is also portable: I read a couple of years ago it was in the original Bourne sh tho I lost the url, and it's mandated in the debian specs for sh.) If not, then there's no point discussing it further, and I wish you luck with all your future Python code.

Quote:
Hmm, do you think backward compatibility is essential for this tool ? Some of the features are not actually documented and I don't think global useflags edition through euse has an actual interest nowadays.

Ahh the new-school "Can I just call it 'traditional cruft' and forget about it, instead of implementing it?" philosophy. No, you can't: fulfil the user-requirements, don't argue about them. Or stop pretending to be in this for anything other than your own amusement, and get off the pot. You're wasting our time, and just because the software is free, that does not mean our time is.
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Thu Feb 21, 2013 1:29 am    Post subject: Reply with quote

Well, apinsard, if you're interested in creating a tool, here are several people who may be of help. It seems clear that some of the "standard" tools (i.e. those in gentoolkit and portage-utils) are out of date or do not completely fulfill the requirements of users. While writing add-ons to flesh out functionality is useful, maybe a more valuable result could be achieved by looking at whether these tools should be updated or replaced.

Here in this thread are already some experienced users who can help with functional requirements from the user perspective, two developers deeply familiar with portage who can confirm functional and technical requirements and offer guidance on where to get help, architecture, standards, testing, and roll-out strategy. Maybe you can even find some collaborators through this discussion or in IRC. :wink:
_________________
patrix_neo wrote:
The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum