On Tue, 22 Nov 2005 21:47:40 +0100 jb benoit <[EMAIL PROTECTED]> wrote:
> Marius Mauch wrote: > > >- Doesn't work with binpkgs (though that's probably also a problem in > >getmaskingstatus() itself) > >- there is more than keyword and p.mask for masking (profiles) > >- the function name is misleading (you're not checking the actual > >masking status) > >- you don't check for non-~arch and package.mask'ed packages > >- you don't check for non-$ARCH ACCEPT_KEYWORDS/package.keywords > >entries > >- other semantic issues I' not going to repeat > >- completely useless without docs. > > > > > > > If this can help, i'll respond to some of your question : > My aims is very different to the one of getmaskingstatus(). Not really, you basically just want to ignore parts of the local config, that's all. > I don't have to check everywere for the status : > The package which status I'm searching were already checked by > getmaskingstatus(). > This is very important. Wrong. getmaskingstatus() doesn't decide if a package is masked (gvivsible() does that), it only checks for possible reasons. And if this should be considered for inclusion you *have* to check for all possible masks (though with profiles this gets tricky). > The only 2 thinks I implemented was to search : > > if the package beeing checked is an unstable version, > which can be done only by looking at the supported keywords in the > ebuild. Again wrong. Example: - ebuild foo has KEYWORDS="~x86" - my system has ARCH="amd64" - in package.keywords I have a line "foo ~x86" So while this package isn't even marked as "testing" for my arch your patch would treat it as "stable" (at least that's how I would interpret the output). This example is rather common. > if the package beeing checked is a masked version. > I only need to check is the package was masked in packages.mask, > don't mind the reason for which it's now unmasked. I didn't say anything about checking why it's unmasked, maybe you misunderstood the following comment: "you don't check for non-~arch and package.mask'ed packages" What I mean is when a package is marked stable but in package.mask, your patch simply ignores that (instead of adding a "M" status). > If you thinks this can be usefull, I can made the corection needed. > If you think this is just a bunch of trash, just tell me to forget, > but i'll miss this feature. Well, not trash, but it has a ton of semantic issues (likely more than just the few I posted above) to resolve first making this much more complicated than you probably think. That's probably not important for you or 90% of all users, but if we add such a feature it has to work for at least 98% of all users (ideally of course for 100%). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better.
signature.asc
Description: PGP signature
