On 22 Dec 2008, at 11:33, Daniel Pielmeier wrote:

...
The problem was that the dvdnav USE-flag was masked and you unmasked
the mplayer and dvdnav packages in the first place. This did not
affect the mplayer package that was built without dvdnav support as
the flag was still deactivated. Here [1] is some information from the
maintainer of mplayer.


Yes, although I did understand this already. With apologies to Mr Wong
I find your explanation much clearer than his.


I would prefer it if Portage handled this without USE flag masking
being necessary. If the required package is masked, or needs some
other keyword, then IMO `emerge -p mplayer` should simply give an
"unable to fulfil this USE - packages may be masked or keyworded"
error. IMO `emerge mplayer` should simply install the package without
fulfilling the USE. But clearly there are reasons why this is
impractical.


Stroller.

On Monday 22 December 2008 15:43:24 Stroller wrote:
> On 22 Dec 2008, at 11:33, Daniel Pielmeier wrote:
> > ...
> > The problem was that the dvdnav USE-flag was masked and you unmasked
> > the mplayer and dvdnav packages in the first place. This did not
> > affect the mplayer package that was built without dvdnav support as
> > the flag was still deactivated. Here [1] is some information from the
> > maintainer of mplayer.
>
> Yes, although I did understand this already. With apologies to Mr Wong
> I find your explanation much clearer than his.
>
> I would prefer it if Portage handled this without USE flag masking
> being necessary. If the required package is masked, or needs some
> other keyword, then IMO `emerge -p mplayer` should simply give an
> "unable to fulfil this USE - packages may be masked or keyworded"
> error. IMO `emerge mplayer` should simply install the package without
> fulfilling the USE. But clearly there are reasons why this is
> impractical.

Not so much impractical, more like it's a very bad idea. Portage runs on unix
systems. Of all the basic fundamental ways unix has of going about things,
this one should never be broken:

The machine will do what the admin said it must do. It will do no more and no
less.

An active USE means that the admin wants packages built with that support. The
admin's wishes are very explicit in this regard, there is nothing implied
about it. So if the USE cannot be fulfilled, the only appropriate answer
is "I'm sorry, I cannot do that" and end with an error code.


--
alan dot mckinnon at gmail dot com

On 22 Dec 2008, at 17:51, Alan McKinnon wrote:

...
I would prefer it if Portage handled this without USE flag masking
being necessary. If the required package is masked, or needs some
other keyword, then IMO `emerge -p mplayer` should simply give an
"unable to fulfil this USE - packages may be masked or keyworded"
error. IMO `emerge mplayer` should simply install the package without
fulfilling the USE. But clearly there are reasons why this is
impractical.


...
The machine will do what the admin said it must do. It will do no
more and no

less.

An active USE means that the admin wants packages built with that
support. The
admin's wishes are very explicit in this regard, there is nothing
implied
about it. So if the USE cannot be fulfilled, the only appropriate
answer

is "I'm sorry, I cannot do that" and end with an error code.



But the masking tells Portage to ignore what the admin says, anyway.
So what's the difference?


Stroller.

On 12/22/08, Willie Wong <wwong@princeton.edu> wrote:
> HAHA! Arttu, you also have a typo!
>
> The file should be in
>
> /etc/portage/profile/package.use.mask
>
> Note that 'profile' is singular, not plural.

Sorry, must've been the fever and cold I've been having for the last
couple of days. But true, fever or no fever, always check my typing,
someone off the Intertubes might offer you some clever equivalent of
"rm -rf /"!

One thing to remember is that portage devs are probably ingenious and
lazy (in the positive sense), so they probably do things in a similar
way under /usr/portage and /etc/portage. This gives hints of the
correct paths and file names, maybe even the syntaxes (although in
this case the -dvdnav was a bit unexpected and illogical IMHO).

Of course, /usr/portage has those different sub-directories for, e.g.,
base and many different platforms, but you can keep /etc/portage
"flat". Or this is just my deduction after running Gentoo for 5-6
years, I haven't actually touched the python code much and probably
not pushed the configurations too far either.

I'm very happy if someone points out a "typo" in my logic here -- I'm
sure a little embarrassment early on will save plenty of my time in
the future!

--
Arttu V.

On Tuesday 23 December 2008 00:07:40 Stroller wrote:
> On 22 Dec 2008, at 17:51, Alan McKinnon wrote:
> >> ...
> >> I would prefer it if Portage handled this without USE flag masking
> >> being necessary. If the required package is masked, or needs some
> >> other keyword, then IMO `emerge -p mplayer` should simply give an
> >> "unable to fulfil this USE - packages may be masked or keyworded"
> >> error. IMO `emerge mplayer` should simply install the package without
> >> fulfilling the USE. But clearly there are reasons why this is
> >> impractical.
> >
> > ...
> > The machine will do what the admin said it must do. It will do no
> > more and no
> > less.
> >
> > An active USE means that the admin wants packages built with that
> > support. The
> > admin's wishes are very explicit in this regard, there is nothing
> > implied
> > about it. So if the USE cannot be fulfilled, the only appropriate
> > answer
> > is "I'm sorry, I cannot do that" and end with an error code.
>
> But the masking tells Portage to ignore what the admin says, anyway.
> So what's the difference?

The difference is that when the flag is masked, some dev has determined that
the flag cannot work so will not be used by default. That's OK, a human has
directed that it be so and the software did not try and make a decision - it
just followed instructions. If YOU unmask a masked item, that means that you
want it done anyway and the software should comply.

Some cases are obviously impossible to fulfil - such as installing proprietary
nvidia video drivers on a ppc machine. The driver doesn't exist so it would
be valid in that case to always fail despite what the admin says.

The thread is more about the case where the devs said one thing, the admin
asked for another thing, something needs to be unmasked to fulfil the
instructions and the software decided "stuff it, I'm just going to go right
ahead and merge it anyway with the support I was explicitly asked to
provide". That proposal is ludicrous and completely counter to the Unix way
of doing things.

--
alan dot mckinnon at gmail dot com>
> Stroller.