Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it

2010-03-20 Thread Jean-Marc Hengen
Duncan wrote:

++ - I can only add the saying With freedom comes great responsibility..

Maybe the python herd could maintain a little status page which covers
informations like:
- Estimated python 3 compatibility in respect to the packages in the
main tree.
- Recommendations if installing makes sense or not (e.g. package X gains
feature Y with python 3).
- Recommendations if setting python 3 as system engine makes already
sense or not.
This way gentoo can give its users the tools needed to make a good
decision if python 3 makes sense on his system. For me as a user I need
more time to study if an action makes sense than implementing said
action (e.g. locally masking python 3 - It would not be the first time
masking a package). If one isn't into python, it gets even more complicated.


[gentoo-dev] EAPI 2 policy for portage tree

2008-12-08 Thread Jean-Marc Hengen


I like to write about an observation about gentoo, I made the past 
weeks, which does frustrate me personally a little bit, mainly because 
it makes administration a bit harder for me. It could be considered as 
an issue or as yet another case of When you play with unstable 
packages, you're on your own.. It's about EAPI 2 and maybe it isn't 
worth changing anything with portage 2.1.6 on the way, but I guess, with 
future EAPI's such a situation could be repeated, so maybe there's 
interest in discussing it. If I'm to late and missed the discussion, I 
apologize for the spam.

This mail is about EAPI usage in the portage tree. Let me describe it, 
with what happened today: I'm running a mostly stable system (91 of 1255 
installed packages are unstable), but I test here and there some 
packages. On of the packages, which I installed and is currently masked 
unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy 
with it so far. Today, while updating, portage wanted to downgrade cmake 
to the stable release, due to all cmake 2.6.x version masked by EAPI 2. 
The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a 
bug). My rule of thumb is to only use unstable on none system packages 
after checking, what can go wrong with the unstable package and if I can 
afford the worst case. Generally I consider portage to be a no-go as 
unstable package. So I'm in the situation, where I used cmake-2.6.2 on a 
daily basis and like to continue, but I can't with the current state of 
tree and my policies (more precisely: I can't keep current stable 
portage and cmake-2.6.2). My solution to the problem, was to copy the 
ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. 
The drawback of this workaround is, I could miss important fixes, like 
security fixes.

This isn't the first issue I had with EAPI 2, but they were until now 
always upgrades to new version or new packages, so I abandoned and 
stayed with the current version or didn't install the package at all and 
wait for stable portage with EAPI 2 support. Up till now I could always 
do without those packages, but if I needed one necessarily, I guess, I 
would have backported the ebuild to a older EAPI, rather than upgrading 
portage. What I don't want to say, is that EAPI 2 should be blocked, 
rather the contrary, I look forward to EAPI 2, but from my perspective, 
in the particular case of cmake described above, I rather had added a 
new revision (cmake-2.6.2-r1) with EAPI 2 and the fix and wouldn't touch 
the cmake-2.6.2 ebuild. This has the advantage, that people with a setup 
like mine can continue to use, what they already use and work on the 
cmake ebuild can continue in the new revision. If the new revision fixes 
a security issue, one can mask the old version, with a message with bug 
telling this. So persons like me know, that they have to decide, what to 
do. Certainly one can have a different approach (like the one, that the 
maintainer of cmake took), which I do accept and what I descriped would 
be my solution.

So this is about, if the current policy for using EAPI 2 in the tree 
is really good or it should be improved, when introducing future 
EAPI's, where portage supporting that EAPI is still unstable. My 
proposal would be, to only use new EAPI with a new version or revision 
and also let the last non new EAPI version for unstable packages in the 
tree. This would allow users of that unstable package with stable 
portage to not downgrade or maintain their local version or forced to 
upgrade portage. This would be a start.

I guess, I'm not the only one, having such a setup and it prevent user's 
like me testing unstable packages. I need my PC on a daily basis, I 
can't afford, having it to reinstall, only because I played with 
unstable software. That's why I'm strict, when it comes to system 
packages or important packages to me (and I have to congratulate the 
gentoo devs for their work, my system just works like a charm and I'm 
very happy with gentoo, only hardware failures could make me headaches). 
So what I expect, is to find out, if setups like mine can or should be 
somehow supported. I'm fine, when the outcome is, that I won't be 
supported, then I know and should rethink my strategy to manage my 
gentoo boxes.

With kind regards,
Jean-Marc Hengen, a happy gentoo user

Re: [gentoo-dev] Re: default desktop profile

2007-08-02 Thread Jean-Marc Hengen
Martin Schwier wrote:
 In the libnotify
 case I would vote to make it a static dependency and not useflag
 controllable or at least set the useflag by default.

I see this so:
If upstream thinks, this is an option, the ebuild should reflect this.
If upstream thinks, this is vital, the ebuild should also reflect this.
The decision, if some feature should always be included, when a package
is compiled, should be made by upstream, not by gentoo. There may be
cases, where it is wise to not follow this rule for various reason, but
this should be made by the package maintainer per package and not be a
general rule. This is what makes gentoo a distribution of choices. I
don't like feature A, upstream doesn't it's vital and gentoo give me the
ability to disable/enable the feature A via USE-flags.

As a conclusion, even a lot of peoples likes libnotify, it is not a
reason to make it a static dependency and not USE-flag controllable.
There may be users, like me, who don't like libnotify. If this is seen
as a major profit for most users, doesn't make a lot of problems, its
USE-flag could be enabled by default. Myself, who would not prefer to
have it enabled by default, can easily reverse that in make.conf.

This is only an opinion from a user and reflects a part, on how I see
gentoo and what it makes it for me the best distribution out there.

Jean-Marc Hengen
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] QA issue: No stable skype in Tree

2007-06-15 Thread Jean-Marc Hengen
Vlastimil Babka wrote:
 Maybe you could (either when final 1.4 hits ~arch or on 19th) change the
 RESTRICT=mirror to RESTRICT=fetch in 1.4 and explain the situation
 in pkg_nofetch() via einfo, telling users they either find the distfile
 themselves (might have it on another computer, or get from a friend or
 just maybe have luck with google) or use the ~arch 1.4. This won't
 affect users that already have 1.4 installed, or just have the distfile.

As a current user of skype, I like that idea.

Jean-Marc Hengen
[EMAIL PROTECTED] mailing list