Re: [gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool
Sérgio Almeida wrote:
On Fri, 2009-07-24 at 10:22 +0200, Michael Haubenwallner wrote:
if cmd = 'chdir':
uprofile
..., the automatism for the 'cd' command feels like more
confusing than useful...
Atm, cd just changes dir as it is supposed to. Robert alerted us to the
fact that we can trigger a PRE_CMD on most shells when a CHANGEDIR
occurs.
Instead, provide a command to update the environment for the current
directory, which does search for an .uprofile/ in all the parent
directories when there is no local one.
Additionally, (let the user) define a *new* command that does both
changing directory and updating the environment.
This is the question... Call uprofile manually or detect the profile
automatically? Both capabilities? Mmm...
I'd say leave it to the user to either use the CHANGEDIR event,
or define some alias like 'ucd', or call 'uprofile' manually only.
Eh - provide an uselect-module to select the variant...
Another point: the per-directory profile solution feels like there is no
need to distinguish between user- and directory-profile any more - as
the user-profile would not be anything different than ~/.uprofile/, no?
Yes and no. ~/.uselect/ contains a bin/ environment (prepended to your
PATH by /etc/profile or something) a env.d/ and most probabily
something else that gets executed uppon login.
This does not invalidate you having a ~/.uprofile/. uprofile will
configure your ~/.uselect/ and your environment variables. Your user
profile will not be interpreted by python, uprofile turns profile files
(from python) into bin/ and env.d/ environment on your ~/.uselect.
Ohw, there is .uselect/{bin,env.d}/ ...
What about a per-directory .uselect/{bin,env.d}/ too?
I'd like to set up the complete environment/profile for a development project,
to completely take precedence over the users' environment/profile who are
working on that project, to have something like this order:
PATH=/my/project/.uselect/bin:/home/user/.uselect/bin:/etc/.uselect/bin:/usr/bin:/bin
Maybe this already is how it works?
This may seem confusing, but that's the best way I can explain. Later
this weekend will send a call for ideas/call for modules to the dev
list to get everyone known with the uselect environment. I'm just
finishing cleaning up the code to start commiting and using git
branches.
Whenever I come to test uselect/uprofile, I'll do this in Gentoo Prefix
on several platforms, not on my stable Gentoo Desktop...
Thank you!
/haubi/
[gentoo-dev] Lastrite: media-sound/gnusound
# Samuli Suominen ssuomi...@gentoo.org (27 Jul 2009) # Doesn't compile. Doesn't respect environment. # Segmentation faults. Bugs #252675, #273405, #276560 media-sound/gnusound Wasted a good afternoon with this junk.
Re: [gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool
On Mon, 2009-07-27 at 10:33 +0200, Michael Haubenwallner wrote: I'd say leave it to the user to either use the CHANGEDIR event, or define some alias like 'ucd', or call 'uprofile' manually only. Eh - provide an uselect-module to select the variant... Never though of that... Nice idea! Maybe this already is how it works? It's how it will work =) atm only /bin works and per-user (not yet per folder) Whenever I come to test uselect/uprofile, I'll do this in Gentoo Prefix on several platforms, not on my stable Gentoo Desktop... Just did a commit this afternoon. Feel free to try it out. I haven't implemented any modules besides my test module python and it's most probably buggy because of python-config dependency. sh install.sh should do the work. http://git.overlays.gentoo.org/gitweb/?p=proj/uselect.git;a=summary I'm starting profiles implementation today and will have more active commits. Cheers, Sérgio -- Sérgio Almeida - meph...@gmail.com mephx @ freenode signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Qt3 deprecation
On Sun, Jul 26, 2009 at 3:25 PM, Ben de Grootyng...@gentoo.org wrote: Dear fellow devs, We would like to draw your attention to the fact that the Gentoo Qt team now officially discourages further usage of Qt3. Version 3 is no longer being developed or supported upstream. All users are strongly encouraged to use Qt version 4 where applicable. This means that we request that no new Qt3-based packages will be introduced to the portage tree. Also, where there is a choice, Qt4 should be preferred over Qt3 by default. We will still do some minimal maintenance and support on the existing Qt3 libs and applications for about another 6 months. This will give application maintainers the time to upgrade or look for alternatives. After this period we will move the Qt3 libs and apps along with KDE3 into an overlay where users of those legacy packages can maintain them. If you have a package for which both Qt3 and Qt4 versions exist, please have the Qt4-based version marked stable (if it isn't already) within the next few months and remove the legacy Qt3-based version, if possible. Thanks, Ben de Groot Gentoo Qt team lead MythTV still uses Qt3 and there is NO way that the Qt4 based MythTV could even remotely be considered stable. It is still undergoing constantly changing and there are many codepaths that are incomplete. -- Doug Goldstein
Re: [gentoo-dev] Qt3 deprecation
Ben de Groot wrote: Dear fellow devs, We would like to draw your attention to the fact that the Gentoo Qt team now officially discourages further usage of Qt3. Version 3 is no longer being developed or supported upstream. All users are strongly encouraged to use Qt version 4 where applicable. Wait a minute. Qt3 is deprecated, but people are still adding new Qt3-based packages to the tree: On the 26th, scarabeus added gerix, as seen on our front page p.g.o feed: net-wireless/gerix-0.20 Qt3 Based aircrack GUI . . . wtf? signature.asc Description: OpenPGP digital signature
