Re: [gentoo-dev] Resurrecting the seeds project
Donnie Berkholz wrote: > On 08:58 Mon 12 Nov , Aniruddha wrote: > >> I am interested in resurrecting the 'seeds' project ( >> http://www.gentoo.org/proj/en/seeds/ ). I first heard from it when I >> announced my stage 4 project ( >> http://forums.gentoo.org/viewtopic-t-610904-highlight-.html ). >> It's is important to know that it is my intention to stay as close as >> possible to the original stage 3. Every change will be documented. >> >> I expect to build the first stage 4 this week and I really would like to >> see these stage 4's to be used to get the seeds project started again. >> How can we make this possible? >> > > You might like to take a look at http://code.google.com/p/seed-linux/ > > Thanks, > Donnie > Thanks for the reply. However I am looking more for using the current infrastructure ( #gentoo-seeds , http://overlays.gentoo.org/proj/seeds/). That way we can breathe life in the gentoo-seeds project again instead of the google-seeds ;) Regards, Aniruddha
Re: [gentoo-dev] Re: Re: Re: eselect_zenity: alpha eselect GUI
On Mon, 12 Nov 2007 09:13:32 +
Steve Long <[EMAIL PROTECTED]> wrote:
> >> Use of ((EUID)) is also quicker.
> >
> > Quicker than what?
>
> Than [[ ${UID} -ne 0 ]] ie the existing code. What did you think the
> discussion was about?
Well, I was kind of wondering... Because it looked to me like you were
implying that EUID is faster than UID. Which is clearly untrue...
> > It's quicker than the almost-as-bad [[ -w ]] because
> > it doesn't check things. Being EUID 0 does not mean you can write to
> > anything you want. Having [[ -w ]] does not mean you can write to
> > anything you want either, of course, but it's a slight step up from
> > EUID.
>
> Sure, since you don't check [[ -w ]] you check [[ -w path ]].
...which is exactly what we were discussing, as you know fine well.
> > Checking for EUID or UID or anything else as Donnie was proposing is
> > wrong anyway, for a very simple reason. Consider, for example,
> > eselect kernel. Requiring ROOT to change the /usr/src/linux symlink
> > is a nuisance, since any responsible user will have all of /usr/src
> > managed by a normal user.
> >
> Indeed; and all I did was a) present a better way to write the
> existing check, and b) mention a better test that could be used,
> which you are now discussing (for a change.)
The existing check is completely wrong. You're presenting a less
readable but marginally faster incorrect alternative in a place where
a small constant performance factor gain is irrelevant.
> >> Whatever. Requiring root for certain tasks has a long history:
> >
> > On the kernel side.
>
> Hmm, I'm sure I've used several apps which required root over the
> years.
Then get them fixed.
> >> Further, group membership, while not as fine-grained as ACLs or
> >> Linux Capabilities, is still a legitimate security mechanism.
> >
> > Which isn't what eselect is providing. eselect has nothing to do
> > with security.
> >
> So what? The system still needs to be secured, and the user who runs
> eselect does require certain privileges, which is very much the
> purview of security.
And there is no correct way to test whether those privileges are
available using bash, which brings us back to my original point.
> I thought you were going to mention the latter two; the question
> remains: why not just do so in the first place, in the spirit of
> communication and development?
Because I assume I'm dealing with an audience that more or less
understands the topic at hand and doesn't need every single detail
explicitly spelt out.
> None of the above stop a writeable check being useful imo: if the
> permission isn't there as far as the kernel's concerned, there's no
> point trying the rest of it.
Except that [[ -w ]] can return false negatives.
> > Well, you're jumping in on a discussion about die implementations,
> > so I assume you're fully aware of the relative merits and
> > implementation details of all four solutions already. But if you're
> > not... Try pointing out which the four solutions don't you
> > recognise and understand. Explaining the implications of any one of
> > them is non-trivial, so it's not something I'll do unnecessarily.
> >
> Don't bother: for some reason I don't feel very motivated by
> this "conversation". I was discussing how to handle signals, btw, and
> sharing something I learnt with others (which you clearly did not know
> yourself.)
Had you bothered to study any of the newer die implementations, you'd
realise that I know exactly how all that works.
> > So how, exactly, do I have something to learn from those before me?
>
> Your statement that BASH's lack of exceptions means you cannot
> implement correct solutions tells me you have much to learn
> technically
Not at all. If you think they can, it shows you don't know enough about
Unix signal handling and obscure-but-sadly-common side cases.
> quite apart from the social issues which have already been documented
> and discussed ad nauseam.
Repeating something over and over doesn't make it true.
> > And why do you feel the need to comment when you don't know what the
> > eselect die implementation is or how the changes to it introduced in
> > Paludis make it better?
> >
> As stated, I was sharing knowledge and pointing out improvements and
> possible solutions.
You don't know what the existing solution is or what the improved
solution being proposed is, so how can you point out improvements?
> You should try it some time
Funnily enough, that's exactly what I did when I suggested moving from
the original eselect implementation to the newer Paludis implementation.
> (nice to see that you
> can actually discuss, as above, but it's a shame it still takes 2 or
> 3 mails before you will. Good luck with that.)
Mmm, let's see.
First email: suggested moving from the original eselect die to the
newer Paludis die. More than enough information there for anyone
involved in the discussion to understand and make the changes.
Your reply: missing the point about signal
Re: [gentoo-dev] Phase invariancy and exclusivity requirements
On Mon, 12 Nov 2007 13:26:46 +0100 "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote: > What exactly is the difference between this valid situation and the > previous invalid one? It's basically down to whether pkg_setup has to be run with the same system state as pkg_preinst / pkg_postinst. If arbitrary changes to the live system are permitted between pkg_setup and pkg_preinst then the rules I gave are too strict. But I suspect that arbitrary changes will cause breakages to quite a few packages, and given that there're fairly nice solutions even with the stricter requirements, I'd say that the safe rules are better. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: eselect_zenity: alpha eselect GUI
Ciaran McCreesh wrote:
On Mon, 12 Nov 2007 09:13:32 +
Steve Long <[EMAIL PROTECTED]> wrote:
Use of ((EUID)) is also quicker.
Quicker than what?
Than [[ ${UID} -ne 0 ]] ie the existing code. What did you think the
discussion was about?
Well, I was kind of wondering... Because it looked to me like you were
implying that EUID is faster than UID. Which is clearly untrue...
It's quicker than the almost-as-bad [[ -w ]] because
it doesn't check things. Being EUID 0 does not mean you can write to
anything you want. Having [[ -w ]] does not mean you can write to
anything you want either, of course, but it's a slight step up from
EUID.
Sure, since you don't check [[ -w ]] you check [[ -w path ]].
...which is exactly what we were discussing, as you know fine well.
Checking for EUID or UID or anything else as Donnie was proposing is
wrong anyway, for a very simple reason. Consider, for example,
eselect kernel. Requiring ROOT to change the /usr/src/linux symlink
is a nuisance, since any responsible user will have all of /usr/src
managed by a normal user.
Indeed; and all I did was a) present a better way to write the
existing check, and b) mention a better test that could be used,
which you are now discussing (for a change.)
The existing check is completely wrong. You're presenting a less
readable but marginally faster incorrect alternative in a place where
a small constant performance factor gain is irrelevant.
Whatever. Requiring root for certain tasks has a long history:
On the kernel side.
Hmm, I'm sure I've used several apps which required root over the
years.
Then get them fixed.
Further, group membership, while not as fine-grained as ACLs or
Linux Capabilities, is still a legitimate security mechanism.
Which isn't what eselect is providing. eselect has nothing to do
with security.
So what? The system still needs to be secured, and the user who runs
eselect does require certain privileges, which is very much the
purview of security.
And there is no correct way to test whether those privileges are
available using bash, which brings us back to my original point.
I thought you were going to mention the latter two; the question
remains: why not just do so in the first place, in the spirit of
communication and development?
Because I assume I'm dealing with an audience that more or less
understands the topic at hand and doesn't need every single detail
explicitly spelt out.
None of the above stop a writeable check being useful imo: if the
permission isn't there as far as the kernel's concerned, there's no
point trying the rest of it.
Except that [[ -w ]] can return false negatives.
Well, you're jumping in on a discussion about die implementations,
so I assume you're fully aware of the relative merits and
implementation details of all four solutions already. But if you're
not... Try pointing out which the four solutions don't you
recognise and understand. Explaining the implications of any one of
them is non-trivial, so it's not something I'll do unnecessarily.
Don't bother: for some reason I don't feel very motivated by
this "conversation". I was discussing how to handle signals, btw, and
sharing something I learnt with others (which you clearly did not know
yourself.)
Had you bothered to study any of the newer die implementations, you'd
realise that I know exactly how all that works.
So how, exactly, do I have something to learn from those before me?
Your statement that BASH's lack of exceptions means you cannot
implement correct solutions tells me you have much to learn
technically
Not at all. If you think they can, it shows you don't know enough about
Unix signal handling and obscure-but-sadly-common side cases.
quite apart from the social issues which have already been documented
and discussed ad nauseam.
Repeating something over and over doesn't make it true.
And why do you feel the need to comment when you don't know what the
eselect die implementation is or how the changes to it introduced in
Paludis make it better?
As stated, I was sharing knowledge and pointing out improvements and
possible solutions.
You don't know what the existing solution is or what the improved
solution being proposed is, so how can you point out improvements?
You should try it some time
Funnily enough, that's exactly what I did when I suggested moving from
the original eselect implementation to the newer Paludis implementation.
(nice to see that you
can actually discuss, as above, but it's a shame it still takes 2 or
3 mails before you will. Good luck with that.)
Mmm, let's see.
First email: suggested moving from the original eselect die to the
newer Paludis die. More than enough information there for anyone
involved in the discussion to understand and make the changes.
Your reply
Re: [gentoo-dev] Re: Re: Re: eselect_zenity: alpha eselect GUI
On Tue, 13 Nov 2007 11:13:52 -0500 Dan <[EMAIL PROTECTED]> wrote: > Mind taking this off list? As much fun as it is to see two people > run around in circles blindfolded with pointy sticks, It really > doesn't belong here. Would you mind not needlessly quoting ~9KB of text, next time? Thanks! :) Kind regards, JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] eselect_zenity: alpha eselect GUI
Donnie Berkholz wrote: > Hey all, > > I've been wanting a GUI for eselect lately, so tonight I hacked up the > start of one called eselect_zenity [1]. It only works for the most > trivial modules so far -- it has to parse eselect output, so special > parsers need to be written for each type. eselect_zenity uses > (surprise!) Zenity, a shell-scripting interface to GTK+. > > I'd appreciate any patches you'd like to contribute to add functionality > or fix bugs. > > Thanks, > Donnie > > 1. http://dev.gentoo.org/~dberkholz/eselect_zenity/ > This is something really good. I've been thinking that Gentoo could use a few small GUI utilities. Items such as a notification-applet for GLSA bits that affect your system. Similiar to Ubuntu's tool when there's updates that need to be applied. Additionally, I'd like to see all these utilities wrapped via PolicyKit rather then using gksu and kdesu applications. PolicyKit is definitely the way forward on designing custom, granular permissions and not relying on root in a GUI environment. While I haven't had much time to work on the bits, Gentopia does contain PolicyKit (though the 0.7 snapshots that appear do have some issues and you should stick to the 0.6 series). It's hopefully going to be the way forward for Gentoo to use PolicyKit. As many may know, Fedora has made this commitment and Ubuntu is starting to contribute more back and be involved a bit more. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Doug Klima schrieb: > While I haven't had much time to work on the bits, Gentopia does contain > PolicyKit (though the 0.7 snapshots that appear do have some issues and > you should stick to the 0.6 series). It's hopefully going to be the way > forward for Gentoo to use PolicyKit. As many may know, Fedora has made > this commitment and Ubuntu is starting to contribute more back and be > involved a bit more. The gui project peoples along with two contributors and upstream already looked into that and at best we could use this notify feature for glsa. Gentoo is just too different to sanely work with it for full updates. Stuff like selecting useflags, outputting important changes, needed configuration updates afterwards and some more issues are plain not doable with packagekit. Though there is some work going on to get an abstraction layer for all three known package managers that work with the tree to make sure such a notify can be done. Greetz Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
On Sun, 2007-11-11 at 21:01 +0200, Petteri Räty wrote: > I plan to make the java eclasses use the EAPI 1 Any chance we can *at least* wait until we have a release out the door that has a portage version which supports these features *before* we start trying to use them in the tree? Our general rule was to not use features for 1+ years since it was added to a *stable* portage before we started using them. Now, this isn't so much of an issue with individual ebuilds, but you're talking about changing how the Java eclasses work, essentially blocking *anyone* using an older portage (including everyone installing from 2007.0 media) from using any package which inherits the eclass. Also, we should really think about this sort of thing before we start using it. How are we going to support EAPI changes in eclasses? What if I have an eclass with EAPI=1 features and I want to add some EAPI=2 features? I think allowing EAPI=* globally in an eclass should be prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds, only. In other words, you'd need new EAPI=1 eclasses for your EAPI=1 ebuilds. Either that, or some way to say something like: "execute code path A for EAPI=0 and execute code path B for EAPI=1" or something similar. I would suspect that the "best" current solution is to check EAPI in the individual functions and perform the right actions based on those functions, rather than marking an entire eclass. After all, only EAPI=* functions need to be "hidden" behind EAPI. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
On Tue, 13 Nov 2007 12:22:03 -0800 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > Any chance we can *at least* wait until we have a release out the door > that has a portage version which supports these features *before* we > start trying to use them in the tree? Our general rule was to not use > features for 1+ years since it was added to a *stable* portage before > we started using them. That was only the case because previously, using new features that Portage didn't support would cause horrible breakage. Now, instead, the ebuilds show up as being masked. > Now, this isn't so much of an issue with individual ebuilds, but > you're talking about changing how the Java eclasses work, essentially > blocking *anyone* using an older portage (including everyone > installing from 2007.0 media) from using any package which inherits > the eclass. They just need to upgrade their package manager first. Easy. > Also, we should really think about this sort of thing before we start > using it. How are we going to support EAPI changes in eclasses? What > if I have an eclass with EAPI=1 features and I want to add some EAPI=2 > features? I think allowing EAPI=* globally in an eclass should be > prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds, > only. Doing an entire eclass for one specific EAPI generally isn't a good idea since it's fairly likely that EAPI bumps will be a fairly common thing. > In other words, you'd need new EAPI=1 eclasses for your EAPI=1 > ebuilds. Either that, or some way to say something like: "execute > code path A for EAPI=0 and execute code path B for EAPI=1" or > something similar. I would suspect that the "best" current solution > is to check EAPI in the individual functions and perform the right > actions based on those functions, rather than marking an entire > eclass. After all, only EAPI=* functions need to be "hidden" behind > EAPI. A solution with EAPI-agnostic code in foo-common.eclass and EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably more readable and maintainable in most cases. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Markus Ullmann wrote: > Doug Klima schrieb: > >> While I haven't had much time to work on the bits, Gentopia does contain >> PolicyKit (though the 0.7 snapshots that appear do have some issues and >> you should stick to the 0.6 series). It's hopefully going to be the way >> forward for Gentoo to use PolicyKit. As many may know, Fedora has made >> this commitment and Ubuntu is starting to contribute more back and be >> involved a bit more. >> > > The gui project peoples along with two contributors and upstream already > looked into that and at best we could use this notify feature for glsa. > Gentoo is just too different to sanely work with it for full updates. > Stuff like selecting useflags, outputting important changes, needed > configuration updates afterwards and some more issues are plain not > doable with packagekit. > > Though there is some work going on to get an abstraction layer for all > three known package managers that work with the tree to make sure such a > notify can be done. > > Greetz > Jokey > > I only meant for notification purposes. Not for any updates or automatic merges. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-text/notecase: ChangeLog notecase-1.7.2.ebuild
On 16:06 Tue 13 Nov , Raul Porcel (armin76) wrote:
> 1.1 app-text/notecase/notecase-1.7.2.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-text/notecase/notecase-1.7.2.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-text/notecase/notecase-1.7.2.ebuild?rev=1.1&content-type=text/plain
> inherit eutils fdo-mime
> pkg_postinst() {
> fdo-mime_desktop_database_update
> fdo-mime_mime_database_update
> }
>
> pkg_postrm() {
> fdo-mime_desktop_database_update
> fdo-mime_mime_database_update
> }
Would it be worth adding these defaults into fdo-mime.eclass?
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: eselect_zenity: alpha eselect GUI
On 20:22 Tue 13 Nov , Markus Ullmann wrote: > Doug Klima schrieb: > > While I haven't had much time to work on the bits, Gentopia does contain > > PolicyKit (though the 0.7 snapshots that appear do have some issues and > > you should stick to the 0.6 series). It's hopefully going to be the way > > forward for Gentoo to use PolicyKit. As many may know, Fedora has made > > this commitment and Ubuntu is starting to contribute more back and be > > involved a bit more. > > The gui project peoples along with two contributors and upstream already > looked into that and at best we could use this notify feature for glsa. > Gentoo is just too different to sanely work with it for full updates. > Stuff like selecting useflags, outputting important changes, needed > configuration updates afterwards and some more issues are plain not > doable with packagekit. I'd like to talk in more detail about this with someone, but nobody on #gentoo-guis seemed to know why PackageKit wouldn't work for the simple (no USE flag changes) case. Should I try the -guis mailing list instead? Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Donnie Berkholz wrote: > I'd like to talk in more detail about this with someone, but nobody on > #gentoo-guis seemed to know why PackageKit wouldn't work for the simple > (no USE flag changes) case. Should I try the -guis mailing list instead? Looking at the current feature set of PackageKit, there's no reason we couldn't add support for Gentoo. However, PackageKit is really meant for binary distros, and some design choices really rely on that. For instance, the PackageKit tray icon will ping the backend for updates every 30 minutes or so (default value), while this is perfectly fine for apt or yum where downloading the list of available updates takes about 2 seconds (just to check the HTTP headers to see if something has changed). Obviously, this can't be kept as is for our case. Also, PackageKit has its own conventions when it comes to packages being available for one platform. Again, its model fits right with binary distros and would require some major tweaking to fit our model, but I don't think it's out of our reach. Maybe one could start writing the search backend and the install/remove backend. That would be a nice step in the right direction :) Cheers, Rémi -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libevent: ChangeLog libevent-1.3e.ebuild
Jan Kundrát wrote:
> Donnie Berkholz wrote:
>>> if [[ -n "${ver}" ]] && [[ ${ver//[a-zA-Z-]} != "${PV//[a-zA-Z]}" ]] ;
>>> then
>>
>> It isn't terribly likely to become an issue here, but it might be nicer
>> to use [[:alpha:]] than [a-zA-Z].
>
> Is [[:alpha:]] locale-safe?
>
Yes, all POSIX character classes listed here are:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
On Tue, 2007-11-13 at 20:31 +, Ciaran McCreesh wrote: > That was only the case because previously, using new features that > Portage didn't support would cause horrible breakage. Now, instead, the > ebuilds show up as being masked. ...which is just as good as "broken" when it happens to a new user first installing Gentoo and wondering why he can't even follow the directions in the Handbook. What brought me to bring this up was the mention of changing of eclasses which support a large number of ebuilds, effectively masking a significant portion of the tree from our users. Let's say that I added EAPI=1 to eutils.eclass because I wanted to use some new EAPI=1 feature in one of the functions. Guess what? I've now managed to mask *portage* for users of older portage versions. In fact, I've managed to mask paludis and pkgcore, too. Yes, this is an extreme example. Yes, it is completely possible. Yes, that user would be completely screwed. > > Now, this isn't so much of an issue with individual ebuilds, but > > you're talking about changing how the Java eclasses work, essentially > > blocking *anyone* using an older portage (including everyone > > installing from 2007.0 media) from using any package which inherits > > the eclass. > > They just need to upgrade their package manager first. Easy. Expecting users to do pretty much anything on their own is broken behavior and should not be relied on for package manager compatibility. > > Also, we should really think about this sort of thing before we start > > using it. How are we going to support EAPI changes in eclasses? What > > if I have an eclass with EAPI=1 features and I want to add some EAPI=2 > > features? I think allowing EAPI=* globally in an eclass should be > > prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds, > > only. > > Doing an entire eclass for one specific EAPI generally isn't a good idea > since it's fairly likely that EAPI bumps will be a fairly common thing. > > > In other words, you'd need new EAPI=1 eclasses for your EAPI=1 > > ebuilds. Either that, or some way to say something like: "execute > > code path A for EAPI=0 and execute code path B for EAPI=1" or > > something similar. I would suspect that the "best" current solution > > is to check EAPI in the individual functions and perform the right > > actions based on those functions, rather than marking an entire > > eclass. After all, only EAPI=* functions need to be "hidden" behind > > EAPI. > > A solution with EAPI-agnostic code in foo-common.eclass and > EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably more > readable and maintainable in most cases. Umm... So in the paragraph above, you say an EAPI-specific eclass isn't a good idea, and here you push it as the proposed solution. Huh? Consistency, please... I guess my real point is that we need to be *really* careful when using this stuff. It is *not* as simple as you make it out to sound. All it takes is one person adding an EAPI into an eclass somewhere to completely screw over a *huge* number of our users. I am just trying to point this out and hopefully get discussion going on how to utilize these great new features without potentially causing damage to our user's machines and our reputation. I still think that EAPI should not be allowed to be set in an eclass globally. All I can see is it causing problems for tons of users who don't have a clue what is happening to their systems. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libevent: ChangeLog libevent-1.3e.ebuild
Steve Long wrote: >> Is [[:alpha:]] locale-safe? >> > Yes, all POSIX character classes listed here are: > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html Thanks for a nice link. If I read section 7.3.1 correctly, [[:alpha:]] always contains those letters, but might contain more, depending on the locale. So it's probably very minor point, but as long as the script runs with user-provided locale, one should be explicit here. Or am I missing something here? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
On Tue, 13 Nov 2007 16:17:59 -0800 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > On Tue, 2007-11-13 at 20:31 +, Ciaran McCreesh wrote: > > That was only the case because previously, using new features that > > Portage didn't support would cause horrible breakage. Now, instead, > > the ebuilds show up as being masked. > > ...which is just as good as "broken" when it happens to a new user > first installing Gentoo and wondering why he can't even follow the > directions in the Handbook. ...so you just ensure that the handbook tells the user to upgrade the package manager as quickly as possible. > What brought me to bring this up was the mention of changing of > eclasses which support a large number of ebuilds, effectively masking > a significant portion of the tree from our users. Let's say that I > added EAPI=1 to eutils.eclass because I wanted to use some new EAPI=1 > feature in one of the functions. Guess what? I've now managed to > mask *portage* for users of older portage versions. In fact, I've > managed to mask paludis and pkgcore, too. Yes, this is an extreme > example. Yes, it is completely possible. Yes, that user would be > completely screwed. Uh huh, so if someone does something immensely stupid things go wrong. How is this anything new? > > > Now, this isn't so much of an issue with individual ebuilds, but > > > you're talking about changing how the Java eclasses work, > > > essentially blocking *anyone* using an older portage (including > > > everyone installing from 2007.0 media) from using any package > > > which inherits the eclass. > > > > They just need to upgrade their package manager first. Easy. > > Expecting users to do pretty much anything on their own is broken > behavior and should not be relied on for package manager > compatibility. Eh? We already expect users to do lots on their own. Are you suggesting that we should take over maintaining everyone's system for them? > > A solution with EAPI-agnostic code in foo-common.eclass and > > EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably > > more readable and maintainable in most cases. > > Umm... So in the paragraph above, you say an EAPI-specific eclass > isn't a good idea, and here you push it as the proposed solution. > Huh? Consistency, please... Read it (and my explanation of it earlier in the thread) until you understand it. There is nothing consistent in what I'm saying. EAPI specific eclasses are a bad idea. Providing EAPI-agnostic eclasses by way of multiple EAPI-specific shell eclasses is a good idea. > I guess my real point is that we need to be *really* careful when > using this stuff. It is *not* as simple as you make it out to > sound. No no, it is as simple as I make it sound (which isn't simple simple, but it isn't any more complicated than things people have to do already). If people stick to a) the way I described of handling non-trivial eclasses that need to care about EAPIs, b) not using new EAPIs on things that are hard deps of the package manager that aren't already in the stageball and c) not nuking the last EAPI 0 versions of a package, there isn't a problem. In particular, there is absolutely no need to wait for updated stages before using EAPI 1 for non-system packages. There isn't even a need to avoid using EAPI 1 of things that are deps of a package manager, so long as there remain EAPI 0 versions that are sufficient to satisfy the dependencies. For example, you could quite happily mark, say, doxygen 1.5 as EAPI 1, without breaking the upgrade or install path for Paludis. Paludis 0.24 or older Portage would simply select doxygen 1.4 rather than 1.5, and then once you'd upgraded to Paludis 0.26 the doxygen 1.5 update would become available. The problem only occurs if either EAPI 0 versions are nuked or if particular versions are required. > All it takes is one person adding an EAPI into an eclass > somewhere to completely screw over a *huge* number of our users. All it takes is one person making any silly change to an eclass to screw over a huge number of users. > I still think that EAPI should not be allowed to be set in an eclass > globally. All I can see is it causing problems for tons of users who > don't have a clue what is happening to their systems. EAPI *can't* be set in an eclass correctly anyway because EAPI is allowed to (and likely will in the future) change the behaviour of inherit. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
On Wed, 14 Nov 2007 00:39:50 + Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > Read it (and my explanation of it earlier in the thread) until you > understand it. There is nothing consistent in what I'm saying. ...bleh. *in*consistent. NNeee oe... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
Chris Gianelloni kirjoitti: > On Sun, 2007-11-11 at 21:01 +0200, Petteri Räty wrote: >> I plan to make the java eclasses use the EAPI 1 > > Any chance we can *at least* wait until we have a release out the door > that has a portage version which supports these features *before* we > start trying to use them in the tree? Our general rule was to not use > features for 1+ years since it was added to a *stable* portage before we > started using them. Now, this isn't so much of an issue with individual > ebuilds, but you're talking about changing how the Java eclasses work, > essentially blocking *anyone* using an older portage (including everyone > installing from 2007.0 media) from using any package which inherits the > eclass. I took this into consideration from the start. You misunderstood my plans. I don't plan to just stick it globally for all current Java ebuilds as there is nothing in EAPI=1 that would warrant that. You can see my plans in more detail in a later post in this thread. > > Also, we should really think about this sort of thing before we start > using it. How are we going to support EAPI changes in eclasses? As said in this thread you really can't set EAPI in an eclass. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
On Wed, 2007-11-14 at 00:39 +, Ciaran McCreesh wrote: > > Umm... So in the paragraph above, you say an EAPI-specific eclass > > isn't a good idea, and here you push it as the proposed solution. > > Huh? Consistency, please... > > Read it (and my explanation of it earlier in the thread) until you > understand it. There is nothing consistent in what I'm saying. You are *so* correct. There really is nothing consistent in your replies. Rather, you've decided to pick and choose how you respond to maximize insult. It's *so* much easier to simply avoid any potential issues than to actually discuss them. As such, I've decided to quit responding to this thread until someone who wishes to actually participate in a discussion, rather than trying to "win" it comes along. Thank you for your input and have a nice day. > > I still think that EAPI should not be allowed to be set in an eclass > > globally. All I can see is it causing problems for tons of users who > > don't have a clue what is happening to their systems. > > EAPI *can't* be set in an eclass correctly anyway because EAPI is > allowed to (and likely will in the future) change the behaviour of > inherit. ...and this proves my point. Rather than simply stating this, you decided to post $diety knows how many lines of completely worthless information again and again. Had you simply said *exactly this* at the beginning, the thread/discussion would have been over. This is exactly what people mean when they say that they feel that you are not participating in discussions fairly. It's like you specifically hold back information that you know and bait people into saying things simply so you call put out the ace from your sleeve and point out how someone else is wrong. Yay! You "win". -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
On Tue, 13 Nov 2007 17:25:44 -0800 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > EAPI *can't* be set in an eclass correctly anyway because EAPI is > > allowed to (and likely will in the future) change the behaviour of > > inherit. > > ...and this proves my point. Rather than simply stating this, you > decided to post $diety knows how many lines of completely worthless > information again and again. Had you simply said *exactly this* at > the beginning, the thread/discussion would have been over. Er, I did. Read my first post to the thread. That is exactly what I said. Then, once you've done that, read other people's questions, which expand upon the original topic and which can't be handled simply by shoving EAPI in each ebuild and doing nothing else. > This is exactly what people mean when they say that they feel that > you are not participating in discussions fairly. What. Please explain how my original post to this thread wasn't sufficient to answer the original question, and how other related but more complex questions that other people posted later on are answered merely by that. I think you should go back, read the whole thread ordered by date and then consider whether an apology for your behaviour is in order. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
Ciaran McCreesh wrote: >> ...which is just as good as "broken" when it happens to a new user >> first installing Gentoo and wondering why he can't even follow the >> directions in the Handbook. > > ...so you just ensure that the handbook tells the user to upgrade the > package manager as quickly as possible. That's already in the handbook. See http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=6#doc_chap2; substitute with the arch of your choice. It's the same file anyway. Nothing wrong with the handbook, and don't nobody break it, neither. Move along, nothing to see here. Scoot scoot. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libevent: ChangeLog libevent-1.3e.ebuild
On Wednesday 14 November 2007 01:33:54 Jan Kundrát wrote: > Steve Long wrote: > >> Is [[:alpha:]] locale-safe? > > > > Yes, all POSIX character classes listed here are: > > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html > > Thanks for a nice link. If I read section 7.3.1 correctly, [[:alpha:]] > always contains those letters, but might contain more, depending on the > locale. So it's probably very minor point, but as long as the script > runs with user-provided locale, one should be explicit here. Or am I > missing something here? If you think [a-zA-Z] is being explicit then you are clearly missing something. E.g. if you google for the estonian alphabet you'll see a lot of ansi letters are after z in that alphabet. So on estonian locales those letters won't be included in [a-z] but they will be included in [:alpha:]. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
[gentoo-dev] packages.gentoo.org lives!
After a LOT of development, Gentoo Infra is pleased to announce the return of the new packages.gentoo.org site. The new site is a complete rewrite. If you had bookmarks to the old style of URL, please consult the FAQ for the new form. We are NOT rewriting these URLs: '/packages/?category=media-sound;name=mp3unicode' (The new form is '/package/media-sound/mp3unicode'). The site is available at: http://packages.gentoo.org/ Please read the entire FAQ before asking any questions! http://packages.gentoo.org/faq/ Thanks to everybody that worked on this: - jokey, starting this version - cla, the visual template for this version - robbat2, way too much coding and infra wrangling -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpIbbNXVsBZi.pgp Description: PGP signature
[gentoo-dev] Re: packages.gentoo.org lives!
Robin H. Johnson wrote: > After a LOT of development, Gentoo Infra is pleased to announce the > return of the new packages.gentoo.org site. The new site is a complete > rewrite. Yay! Nice work guys. > Please read the entire FAQ before asking any questions! > http://packages.gentoo.org/faq/ Does this count as a rendering bug? Seems to be missing the black/purple banner bit. http://dev.gentoo.org/~dirtyepic/misc/pgologo.png -- looks like christmas at fifty-five degrees this latitude weakens my knees EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: packages.gentoo.org lives!
On Tue, Nov 13, 2007 at 10:14:57PM -0600, Ryan Hill wrote: > > Please read the entire FAQ before asking any questions! > > http://packages.gentoo.org/faq/ > Does this count as a rendering bug? Seems to be missing the > black/purple banner bit. > http://dev.gentoo.org/~dirtyepic/misc/pgologo.png Not a rendering bug per se, but the smallness of your font shows that we need a much narrower version of the logo. There isn't meant to be the big black area at the top like, the main gentoo.org site. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpw3NllsmRvN.pgp Description: PGP signature
[gentoo-dev] Re: packages.gentoo.org lives!
Ryan Hill <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 13 Nov 2007 22:14:57 -0600: >> Please read the entire FAQ before asking any questions! >> http://packages.gentoo.org/faq/ > > Does this count as a rendering bug? Seems to be missing the > black/purple banner bit. > > http://dev.gentoo.org/~dirtyepic/misc/pgologo.png FWIW, I get a similar effect in Konqueror (3.5.8), so it's not just FF. Congrats in any case. I was just missing it the other day, trying to figure out what a missing linux-headers revision changelog entry was supposed to be before I upgraded the package. I eventually dug it out of viewcvs, but meanwhile, I was missing the packages.gentoo notes. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: packages.gentoo.org lives!
Robin H. Johnson wrote: > There isn't meant to be the big black area at the top like, the main > gentoo.org site. But shouldn't there be some sort of area at the top with links to the other parts of the site, as the other pages do (the navstrip across the top)? Right now there's zero integration with the gentoo.org site, and even the old p.g.o had at least minimal integration with the other parts of our site. . . . or should this be filed in a p.g.o bug. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libevent: ChangeLog libevent-1.3e.ebuild
Jan Kundrát wrote:
> Steve Long wrote:
>>> Is [[:alpha:]] locale-safe?
>>>
>> Yes, all POSIX character classes listed here are:
>> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html
>
> Thanks for a nice link. If I read section 7.3.1 correctly, [[:alpha:]]
> always contains those letters, but might contain more, depending on the
> locale. So it's probably very minor point, but as long as the script
> runs with user-provided locale, one should be explicit here. Or am I
> missing something here?
>
No, that's about the size of it-- if you you'd like to tie it to ASCII,
irrespective of locale, that's fair enough. It depends on what you're up to
(sorry, I don't have time to go digging through code to see what this
applies to) but in the /general/ case it's better to use locale-neutral
character-classes, since it makes scripts much more useful.
Setting LC_ALL=C temporarily is not a good idea, since it overrides
LC_CTYPE. The most common usage for that is for sort order; where that's
needed it's better to use LC_COLLATE. (man 7 locale)
Quick example showing why the double-bracket appears:
if [[ ${v:0:1} != [[:alpha:]_] || $v = *[^[:alnum:]_]* ]]; then
errMsg $"$v is not a valid identifier"
return 1
fi
Getting to know these is really helpful, imo, especially since they apply to
_all_ the utilities like tr, sed, grep, awk -- and ed ofc ;)
$"text" is for i18n in bash via gettext, akin to _"foo" in C. Can't say I've
used it yet, though :p
--
[EMAIL PROTECTED] mailing list
