Re: [gentoo-user] Re: package.provided syntax for overlay

[Mick]

On Monday 20 Feb 2017 13:23:15 Neil Bothwick wrote:
> On Mon, 20 Feb 2017 14:07:39 +0100, Kai Krakow wrote:
> > > > Another option is to copy/symlink the specific package you want
> > > > from the bar overlay to your local overlay and do not include the
> > > > bar overlay in repos.conf.
> > > 
> > > Sorry for being dense.  Do you mean first add the overlay with
> > > 'layman -a bar', then symlink the particular package to my local
> > > overlay?  How will I be updating this package in the future, if I do
> > > not have the 'bar' overlay settings
> > > in /etc/portage/repos.conf/layman.conf?
> > > 
> > > I'm trying to understand the benefit of doing it as you suggest
> > > above ...  :-/
> > 
> > You could package.mask */*::bar and then only unmask the needed bits.
> 
> That does seem a cleaner way of doing it. When I first did this, that
> option wasn't available.

Thank you both, eventually I used Kai's suggestion, rather than having to mask 
a package at a time that entrance was pulling in as dependencies.

Entrance works fine, other than the pam config it ships with which is not 
working at all on a non-gnome gentoo system.  I need to brush up on pam, which 
I have been avoiding it seems forever and this may be the excuse I needed to 
do it.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: package.provided?

[Kai Krakow]

Am Tue, 14 Feb 2017 23:40:37 +
schrieb Neil Bothwick :

> On Tue, 14 Feb 2017 23:00:03 +0100, Johannes Rosenberger wrote:
> 
> > I find  the package.*-dirs very nice, too. Unfortunately, the tools
> > like emerge, flaggie etc. seem to not always use the same file to
> > write to, so the files get messed up over time.  
> 
> Portage always writes to the end of the last file in the directory, to
> make sure that its entry is not overridden by a subsequent entry. I
> create an empty file called zzz-auto-unmask in package.use etc. Then I
> can move the settings from that file to a more suitable place.

This is also what I did, with exactly the same name. :-)

-- 
Regards,
Kai

Replies to list-only preferred.


pgpmopalUe9ka.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-user] Re: package.provided syntax for overlay

[Neil Bothwick]

On Mon, 20 Feb 2017 14:07:39 +0100, Kai Krakow wrote:

> > > Another option is to copy/symlink the specific package you want
> > > from the bar overlay to your local overlay and do not include the
> > > bar overlay in repos.conf.
> > 
> > Sorry for being dense.  Do you mean first add the overlay with
> > 'layman -a bar', then symlink the particular package to my local
> > overlay?  How will I be updating this package in the future, if I do
> > not have the 'bar' overlay settings
> > in /etc/portage/repos.conf/layman.conf?
> > 
> > I'm trying to understand the benefit of doing it as you suggest
> > above ...  :-/  
> 
> You could package.mask */*::bar and then only unmask the needed bits.

That does seem a cleaner way of doing it. When I first did this, that
option wasn't available.


-- 
Neil Bothwick

Hell:  Filling out the paperwork to get into Heaven.


pgpZwx8JL4T4K.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: package.provided syntax for overlay

[Kai Krakow]

Am Sun, 19 Feb 2017 10:20:41 +
schrieb Mick :

> Hi All,
> 
> Given sddm is not working for my setup, as per bug #608690, I thought
> of trying entrance from the bar overlay.  It wants to pull in
> enlightenment, which I have already installed from the main tree and
> would like to keep it as such:
> 
> # emerge -uaDv entrance
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild U ~] x11-wm/enlightenment-:0.17/::bar 
> [0.20.6:0.17/0.20.6::gentoo] USE="eeze%* nls pam ukit -doc -egl%
> -pm-utils% - static-libs -systemd -wayland (-spell%*)"
> ENLIGHTENMENT_MODULES="appmenu backlight battery bluez4 clock
> conf-applications conf-bindings conf-dialogs conf-display
> conf-interaction conf-intl conf-menus conf-paths conf-performance
> conf-randr conf-shelves conf-theme conf-window-manipulation
> conf-window- remembers connman contact%* cpufreq everything fileman
> fileman-opinfo gadman ibar ibox lokker mixer msgbus music-control
> notification pager pager16%* quickaccess shot start syscon systray
> tasks teamwork temperature tiling winlist wizard xkbswitch -access%
> -packagkit% -wl-desktop-shell* -wl-drm* -wl- fb% -wl-x11* (-conf%*)
> (-geolocation%*) (-packagekit%*) (-pager-plain%*) (- policy-mobile%*)
> (-wl-text-input%*) (-wl-weekeyboard%*) (-wl-wl%*) (- xwayland%*)" 0
> KiB [ebuild  N*] x11-plugins/entrance-::bar  USE="consolekit
> pam -grub - systemd -vkbd" 0 KiB
> 
> 
> So I tried in /etc/portage/package.provided any combination of these:
> 
> x11-wm/enlightenment-:0.17/::bar
> 
> =x11-wm/enlightenment-:0.17
> 
> x11-wm/enlightenment-
> 
> None of which can stop portage dragging in 'x11-
> wm/enlightenment-:0.17/::bar'.  What is the correct syntax to
> block this version of enlightenment from emerging?

The file needs to go to /etc/portage/profile/package.provided to have
any effect. But I guess this is the wrong way for what you're going to
accomplish. You should instead mask that version and then see, what
pulls it in. Or you could try the world upgrade with "--exclude
enlightenment" switch.

-- 
Regards,
Kai

Replies to list-only preferred.


pgpkf2CxgORn5.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-user] Re: package.provided syntax for overlay

[Kai Krakow]

Am Sun, 19 Feb 2017 11:17:11 +
schrieb Mick :

> On Sunday 19 Feb 2017 10:50:31 Neil Bothwick wrote:
> > On Sun, 19 Feb 2017 11:45:27 +0100, Johannes Rosenberger wrote:  
>  [...]  
> > > 
> > > According to the portage manpage 'x11-wm/enlightenment-'
> > > should be the correct syntax.
> > > 
> > > But I think, package.provided is the wrong file at all. The
> > > correct way to accomplish what you want to is masking
> > > 'x11-wm/enlightenment-:0.17/::bar'.  
> > 
> > Agreed.
> > 
> > Another option is to copy/symlink the specific package you want
> > from the bar overlay to your local overlay and do not include the
> > bar overlay in repos.conf.  
> 
> Sorry for being dense.  Do you mean first add the overlay with
> 'layman -a bar', then symlink the particular package to my local
> overlay?  How will I be updating this package in the future, if I do
> not have the 'bar' overlay settings
> in /etc/portage/repos.conf/layman.conf?
> 
> I'm trying to understand the benefit of doing it as you suggest
> above ...  :-/

You could package.mask */*::bar and then only unmask the needed bits.

-- 
Regards,
Kai

Replies to list-only preferred.


pgpbWadLvkH5f.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-user] Re: package.provided?

[Neil Bothwick]

On Tue, 14 Feb 2017 23:00:03 +0100, Johannes Rosenberger wrote:

> I find  the package.*-dirs very nice, too. Unfortunately, the tools like
> emerge, flaggie etc. seem to not always use the same file to write to,
> so the files get messed up over time.

Portage always writes to the end of the last file in the directory, to
make sure that its entry is not overridden by a subsequent entry. I
create an empty file called zzz-auto-unmask in package.use etc. Then I
can move the settings from that file to a more suitable place.


-- 
Neil Bothwick

Bus: (n.) a connector you plug money into, something like a slot machine.


pgplulCBF7AXF.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: package.provided?

[Neil Bothwick]

On Tue, 14 Feb 2017 15:22:50 -0500, Harry Putnam wrote:

> Something else about this entry in `man portage':
> 
> [...]
> SYNOPSIS
>/etc/portage/make.profile/ or /etc/make.profile/
>   site-specific overrides go in /etc/portage/profile/
>   deprecated
>   [...]
> 
> So is the plan to do away with package.provided or just relocate it?

You missed the blank line above deprecated. The lines below it are a list
of files that can go in the profile, the first of which is called
"deprecated"


-- 
Neil Bothwick

SITCOM: Single Income, Two Children, Oppressive Mortgage


pgpQDUW7hso6O.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: package.provided?

[Johannes Rosenberger]

On 14.02.2017 21:22, Harry Putnam wrote:
> Johannes Rosenberger  writes:
>
>>> Can anyone offer suggestions about this... is it even the right way to
>>> proceed?
>>>
>>>
>> Hello!
>>
>> I have portage-2.3.3 installed and in my portage manpage it is mentioned:
>>
>> The file shall reside in etc/(make.profile|portage/(make.)?profile) and
>> the syntax is
>> /- without the '=' in the front.
> Thanks for that.  I'm not at all sure what that line means.
>
> something like /etc/  (then either make a directory named `profile' or
> one named `portage' if necessary) / (then make `profile' if
> necessary.)

That line is a regular expression (like in grep, sed, awk, vim,…):
Parentheses always group something into an atom and pipes mark an
alternative. '?' means that the preceding atom occurs zero or one time.
So the expression means 'etc/' (I missed out the preceding slash),
followed by alternatively 'make.profile' or 'portage/(make.)?profile'.
The latter means 'portage/profile' with an optional 'make.' in between.

As you (hopefully) see, the expression resolves to the three 
alternatives mentioned in the man page.

>
> So, /etc/portage/profile/package.provided
>
> I followed a newish dictum of using the package part as a directory
> name. So /etc/portage/profle/package.provided/FnameAndContentHere
> It worked... thanks again.


I find  the package.*-dirs very nice, too. Unfortunately, the tools like
emerge, flaggie etc. seem to not always use the same file to write to,
so the files get messed up over time.


>
> It worked.. still not getting everything installed but that
> part worked...

Well, that's not too astonishing… ;-)
Especially if you do anything uncommon: I'm trying to build a
musl-clang-4.0.0_rc1 system at the time, currently. And it took me some
days to hack out how to let clang compile itself with incompatible
symbols produced by gcc and clang…

> Something else about this entry in `man portage':
>
> [...]
> SYNOPSIS
>/etc/portage/make.profile/ or /etc/make.profile/
>   site-specific overrides go in /etc/portage/profile/
>   deprecated
>   [...]
>
> So is the plan to do away with package.provided or just relocate it?

No. "deprecated" is one of the files that reside in the profile, just
like "make.profile". It marks a profile as deprecated and contains the
successing profile and optionally upgrading instructions.

[gentoo-user] Re: package.provided?

[Harry Putnam]

Johannes Rosenberger  writes:

>> Can anyone offer suggestions about this... is it even the right way to
>> proceed?
>>
>>
>
> Hello!
>
> I have portage-2.3.3 installed and in my portage manpage it is mentioned:
>
> The file shall reside in etc/(make.profile|portage/(make.)?profile) and
> the syntax is
> /- without the '=' in the front.

Thanks for that.  I'm not at all sure what that line means.

something like /etc/  (then either make a directory named `profile' or
one named `portage' if necessary) / (then make `profile' if
necessary.)

So, /etc/portage/profile/package.provided

I followed a newish dictum of using the package part as a directory
name. So /etc/portage/profle/package.provided/FnameAndContentHere
It worked... thanks again.

It worked.. still not getting everything installed but that
part worked...

Something else about this entry in `man portage':

[...]
SYNOPSIS
   /etc/portage/make.profile/ or /etc/make.profile/
  site-specific overrides go in /etc/portage/profile/
  deprecated
  [...]

So is the plan to do away with package.provided or just relocate it?

[gentoo-user] Re: package.provided messes up emerging of package slots?

[Nikos Chantziaras]

On 09/12/2011 07:31 PM, Pandu Poluan wrote:


On Sep 12, 2011 11:11 PM, Nikos Chantziaras rea...@arcor.de
mailto:rea...@arcor.de wrote:
 
  In my /etc/portage/profile/package.provided, I have this:
 
   media-libs/freetype-1.4_pre20080316-r2
 
  When I try to emerge freetype however, instead of emerging the newer
version, I get:
 
   $ emerge freetype
 
   WARNING: A requested package will not be merged because it is listed
   in package.provided:
 
 freetype pulled in by 'args'
 
   Nothing to merge; would you like to auto-clean packages? [Yes/No]
 
  Trying emerge freetype:2 also won't work.  The only only to emerge
it seems is by using the whole version (emerge =freetype-2.4.6).  Is
this a bug?

Why did you have that line in package.provided, in the first place? Did
you install freetype on your own, without using portage?


Portage installs both freetype-1 as well as freetype-2.  texlive has 
freetype-1 as a dep, and I don't want it installed because I'm not using 
ttf2tfm.




The way I see it, Portage worked perfectly: it saw that you have
installed a certain version of freetype on your own, and it didn't want
to mess up your installed package.

Just delete the line and emerge freetype.


From my point of view, it doesn't work perfectly, because it behaves 
differently when freetype-1 is really installed, and when it's not but 
listed in package.provided.  If I install freetype-1 and type:


  emerge freetype

it will emerge freetype:2.  So the behavior is vastly different between 
having freetype really installed, and when not but listed in 
package.provided.

[gentoo-user] Re: package.provided messes up emerging of package slots?

[Nikos Chantziaras]

On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote:

On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote:

In my /etc/portage/profile/package.provided, I have this:

media-libs/freetype-1.4_pre20080316-r2

When I try to emerge freetype however, instead of emerging the newer
version, I get:

$ emerge freetype

WARNING: A requested package will not be merged because it is listed
in package.provided:

  freetype pulled in by 'args'

Nothing to merge; would you like to auto-clean packages? [Yes/No]

Trying emerge freetype:2 also won't work.  The only only to emerge it
seems is by using the whole version (emerge =freetype-2.4.6).  Is this
a bug?


At least it's inconsistent. I would expect that the emerge with complete
version also fails.


It's slotted, so it shouldn't fail.  Freetype 1 and 2 can be installed 
at the same time.

Re: [gentoo-user] Re: package.provided messes up emerging of package slots?

[Michael Schreckenbauer]

On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote:
 On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote:
  On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote:
  In my /etc/portage/profile/package.provided, I have this:
  media-libs/freetype-1.4_pre20080316-r2
  
  When I try to emerge freetype however, instead of emerging the newer
  
  version, I get:
  $ emerge freetype
  
  WARNING: A requested package will not be merged because it is
  listed
  
  in package.provided:
freetype pulled in by 'args'
  
  Nothing to merge; would you like to auto-clean packages?
  [Yes/No]
  
  Trying emerge freetype:2 also won't work.  The only only to emerge
  it
  seems is by using the whole version (emerge =freetype-2.4.6).  Is
  this
  a bug?
  
  At least it's inconsistent. I would expect that the emerge with complete
  version also fails.
 
 It's slotted, so it shouldn't fail.  Freetype 1 and 2 can be installed
 at the same time.

Yes, that's true for the packages provided by portage. portage does not know 
anything about the freetype you provide, so it shouldn't install any freetype 
from any slot by any command.

Best,
Michael

[gentoo-user] Re: package.provided messes up emerging of package slots?

[Nikos Chantziaras]

On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote:

On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote:

On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote:

On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote:

In my /etc/portage/profile/package.provided, I have this:
 media-libs/freetype-1.4_pre20080316-r2

When I try to emerge freetype however, instead of emerging the newer

version, I get:
 $ emerge freetype

 WARNING: A requested package will not be merged because it is
 listed

 in package.provided:
   freetype pulled in by 'args'

 Nothing to merge; would you like to auto-clean packages?
 [Yes/No]

Trying emerge freetype:2 also won't work.  The only only to emerge
it
seems is by using the whole version (emerge =freetype-2.4.6).  Is
this
a bug?


At least it's inconsistent. I would expect that the emerge with complete
version also fails.


It's slotted, so it shouldn't fail.  Freetype 1 and 2 can be installed
at the same time.


Yes, that's true for the packages provided by portage. portage does not know
anything about the freetype you provide, so it shouldn't install any freetype
from any slot by any command.


I don't see how it doesn't know anything about it, given that it 
requires me to list a full package atom in package.provided.  So it 
always knows which version should be considered as being provided.

Re: [gentoo-user] Re: package.provided messes up emerging of package slots?

[Michael Schreckenbauer]

On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote:
 On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote:
  On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote:
  On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote:
  On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote:
  In my /etc/portage/profile/package.provided, I have this:
   media-libs/freetype-1.4_pre20080316-r2
  
  When I try to emerge freetype however, instead of emerging the
  newer
  
  version, I get:
   $ emerge freetype
   
   WARNING: A requested package will not be merged because
   it is
   listed
   
   in package.provided:
 freetype pulled in by 'args'
   
   Nothing to merge; would you like to auto-clean packages?
   [Yes/No]
  
  Trying emerge freetype:2 also won't work.  The only only to
  emerge
  it
  seems is by using the whole version (emerge =freetype-2.4.6). 
  Is
  this
  a bug?
  
  At least it's inconsistent. I would expect that the emerge with
  complete version also fails.
  
  It's slotted, so it shouldn't fail.  Freetype 1 and 2 can be installed
  at the same time.
  
  Yes, that's true for the packages provided by portage. portage does not
  know anything about the freetype you provide, so it shouldn't install
  any freetype from any slot by any command.
 
 I don't see how it doesn't know anything about it, given that it
 requires me to list a full package atom in package.provided.  So it
 always knows which version should be considered as being provided.

Yes. freetype version 1. So if a package depends on freetype version 1, 
portage assumes, the dep is already installed.
It does not know, where it is installed, or what files it installed. So it has 
to assume, that an emerge of freetype-2 actually could overwrite some of your 
freetype-1 files. Therefore it should not install freetype-2 with any command, 
if you have any version of freetype in package.provided.

Best,
Michael

Re: [gentoo-user] Re: package.provided messes up emerging of package slots?

[Alan McKinnon]

On Mon, 12 Sep 2011 19:49:28 +0300
Nikos Chantziaras rea...@arcor.de wrote:

 On 09/12/2011 07:31 PM, Pandu Poluan wrote:
 
  On Sep 12, 2011 11:11 PM, Nikos Chantziaras rea...@arcor.de
  mailto:rea...@arcor.de wrote:
   
In my /etc/portage/profile/package.provided, I have this:
   
 media-libs/freetype-1.4_pre20080316-r2
   
When I try to emerge freetype however, instead of emerging the
newer
  version, I get:
   
 $ emerge freetype
   
 WARNING: A requested package will not be merged because it is
listed in package.provided:
   
   freetype pulled in by 'args'
   
 Nothing to merge; would you like to auto-clean packages?
[Yes/No]
   
Trying emerge freetype:2 also won't work.  The only only to
emerge
  it seems is by using the whole version (emerge =freetype-2.4.6).
  Is this a bug?
 
  Why did you have that line in package.provided, in the first place?
  Did you install freetype on your own, without using portage?
 
 Portage installs both freetype-1 as well as freetype-2.  texlive has 
 freetype-1 as a dep, and I don't want it installed because I'm not
 using ttf2tfm.
 
 
  The way I see it, Portage worked perfectly: it saw that you have
  installed a certain version of freetype on your own, and it didn't
  want to mess up your installed package.
 
  Just delete the line and emerge freetype.
 
  From my point of view, it doesn't work perfectly, because it behaves 
 differently when freetype-1 is really installed, and when it's not
 but listed in package.provided.  If I install freetype-1 and type:
 
emerge freetype
 
 it will emerge freetype:2.  So the behavior is vastly different
 between having freetype really installed, and when not but listed in 
 package.provided.


That's because a package being installed and being provided are not the
same thing and are treated very differently.

If you install xyz-1.2.3 then portage knows what it did to achieve
that and can deal with it as normal.

If you provide xyz-1.2.3 then portage does not know what *you* did to
achieve that and makes no attempt to deal with it at all. You are
expected to completely 100% deal with all of xyz, including all slots.
man 5 portage mentions that the version number is there in
package.provided so that portage can alert you if some other package
has a dep on a version of xyz you did not provide.

Seen in that light, the behaviour is indeed sensible, just not
consistent if you haven't read the docs yet. I don't think it's wise to
try and change portage's behaviour with this, as Michael said in
another sub-thread portage has no idea what you did so it can't even
try to take control of different slots for fear it might clobber all
your manual hard work



-- 
Alan McKinnnon
alan.mckin...@gmail.com

[gentoo-user] Re: package.provided messes up emerging of package slots?

[Nikos Chantziaras]

On 09/12/2011 10:02 PM, Michael Schreckenbauer wrote:

On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote:

On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote:

On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote:

On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote:

On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote:

In my /etc/portage/profile/package.provided, I have this:
  media-libs/freetype-1.4_pre20080316-r2

When I try to emerge freetype however, instead of emerging the
newer

version, I get:
  $ emerge freetype

  WARNING: A requested package will not be merged because
  it is
  listed

  in package.provided:
freetype pulled in by 'args'

  Nothing to merge; would you like to auto-clean packages?
  [Yes/No]

Trying emerge freetype:2 also won't work.  The only only to
emerge
it
seems is by using the whole version (emerge =freetype-2.4.6).
Is
this
a bug?


At least it's inconsistent. I would expect that the emerge with
complete version also fails.


It's slotted, so it shouldn't fail.  Freetype 1 and 2 can be installed
at the same time.


Yes, that's true for the packages provided by portage. portage does not
know anything about the freetype you provide, so it shouldn't install
any freetype from any slot by any command.


I don't see how it doesn't know anything about it, given that it
requires me to list a full package atom in package.provided.  So it
always knows which version should be considered as being provided.


Yes. freetype version 1. So if a package depends on freetype version 1,
portage assumes, the dep is already installed.
It does not know, where it is installed, or what files it installed. So it has
to assume, that an emerge of freetype-2 actually could overwrite some of your
freetype-1 files. Therefore it should not install freetype-2 with any command,
if you have any version of freetype in package.provided.


I disagree.  A slotted package is practically two different packages 
that simply share the same name.  If one slot is assumed as being 
provided, then that slot should have no effect on the other ones.


With your argument, portage should not install *any* packages at all if 
there's even a single entry in package.provided, because it doesn't know 
what that package installs and therefore *any other* package could 
results in conflicts.

[gentoo-user] Re: package.provided messes up emerging of package slots?

[Nikos Chantziaras]

On 09/12/2011 11:31 PM, Alan McKinnon wrote:

On Mon, 12 Sep 2011 19:49:28 +0300
Nikos Chantziarasrea...@arcor.de  wrote:


On 09/12/2011 07:31 PM, Pandu Poluan wrote:


On Sep 12, 2011 11:11 PM, Nikos Chantziarasrea...@arcor.de
mailto:rea...@arcor.de  wrote:
  
In my /etc/portage/profile/package.provided, I have this:
  
 media-libs/freetype-1.4_pre20080316-r2
  
When I try to emerge freetype however, instead of emerging the
newer
version, I get:
  
 $ emerge freetype
  
 WARNING: A requested package will not be merged because it is
listed in package.provided:
  
   freetype pulled in by 'args'
  
 Nothing to merge; would you like to auto-clean packages?
[Yes/No]
  
Trying emerge freetype:2 also won't work.  The only only to
emerge
it seems is by using the whole version (emerge =freetype-2.4.6).
Is this a bug?

Why did you have that line in package.provided, in the first place?
Did you install freetype on your own, without using portage?


Portage installs both freetype-1 as well as freetype-2.  texlive has
freetype-1 as a dep, and I don't want it installed because I'm not
using ttf2tfm.



The way I see it, Portage worked perfectly: it saw that you have
installed a certain version of freetype on your own, and it didn't
want to mess up your installed package.

Just delete the line and emerge freetype.


   From my point of view, it doesn't work perfectly, because it behaves
differently when freetype-1 is really installed, and when it's not
but listed in package.provided.  If I install freetype-1 and type:

emerge freetype

it will emerge freetype:2.  So the behavior is vastly different
between having freetype really installed, and when not but listed in
package.provided.



That's because a package being installed and being provided are not the
same thing and are treated very differently.

If you install xyz-1.2.3 then portage knows what it did to achieve
that and can deal with it as normal.

If you provide xyz-1.2.3 then portage does not know what *you* did to
achieve that and makes no attempt to deal with it at all. You are
expected to completely 100% deal with all of xyz, including all slots.
man 5 portage mentions that the version number is there in
package.provided so that portage can alert you if some other package
has a dep on a version of xyz you did not provide.


Yes, on a *version*, not on a *slot*, which is in effect a different 
package but simply using the same name.




Seen in that light, the behaviour is indeed sensible, just not
consistent if you haven't read the docs yet. I don't think it's wise to
try and change portage's behaviour with this, as Michael said in
another sub-thread portage has no idea what you did so it can't even
try to take control of different slots for fear it might clobber all
your manual hard work


As I mentioned in my other post, portage should stop working altogether 
then, because conflicts can arise with any other package.  But portage 
*does* allows me to install package foo if I have bar-1.0 listed in 
package.provided.  For the same reason, it should allow me install 
foo:2 if I have a foo in package.provided that belongs to the 
foo:1 slot.

Re: [gentoo-user] Re: package.provided messes up emerging of package slots?

[Pandu Poluan]

On Sep 13, 2011 2:10 AM, Nikos Chantziaras rea...@arcor.de wrote:

 On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote:

 On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote:

 On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote:

 On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote:

 In my /etc/portage/profile/package.provided, I have this:
 media-libs/freetype-1.4_pre20080316-r2

 When I try to emerge freetype however, instead of emerging the newer

 version, I get:
 $ emerge freetype

 WARNING: A requested package will not be merged because it is
 listed

 in package.provided:
   freetype pulled in by 'args'

 Nothing to merge; would you like to auto-clean packages?
 [Yes/No]

 Trying emerge freetype:2 also won't work.  The only only to emerge
 it
 seems is by using the whole version (emerge =freetype-2.4.6).  Is
 this
 a bug?


 At least it's inconsistent. I would expect that the emerge with
complete
 version also fails.


 It's slotted, so it shouldn't fail.  Freetype 1 and 2 can be installed
 at the same time.


 Yes, that's true for the packages provided by portage. portage does not
know
 anything about the freetype you provide, so it shouldn't install any
freetype
 from any slot by any command.


 I don't see how it doesn't know anything about it, given that it requires
me to list a full package atom in package.provided.  So it always knows
which version should be considered as being provided.


Well, Portage in your case only knows 'which' version is provided so
packages that depend on that version can be emerged.

But, Portage has no knowledge of the 'provided' package's files (e.g., no
data about the package in /var/db) since listing a package in
package.provided implies the package is not managed by Portage. This means,
Portage can't do anything to the 'provided' package.

Rgds,

Re: [gentoo-user] Re: package.provided messes up emerging of package slots?

[Michael Schreckenbauer]

On Monday, 12. September 2011 23:42:30 Nikos Chantziaras wrote:
 On 09/12/2011 10:02 PM, Michael Schreckenbauer wrote:
  On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote:
  On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote:
  On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote:
  On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote:
  On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote:
  In my /etc/portage/profile/package.provided, I have this:
media-libs/freetype-1.4_pre20080316-r2
  
  When I try to emerge freetype however, instead of emerging the
  newer
  
  version, I get:
$ emerge freetype

WARNING: A requested package will not be merged
because
it is
listed

in package.provided:
  freetype pulled in by 'args'

Nothing to merge; would you like to auto-clean
packages?
[Yes/No]
  
  Trying emerge freetype:2 also won't work.  The only only to
  emerge
  it
  seems is by using the whole version (emerge
  =freetype-2.4.6).
  Is
  this
  a bug?
  
  At least it's inconsistent. I would expect that the emerge with
  complete version also fails.
  
  It's slotted, so it shouldn't fail.  Freetype 1 and 2 can be
  installed
  at the same time.
  
  Yes, that's true for the packages provided by portage. portage does
  not
  know anything about the freetype you provide, so it shouldn't
  install
  any freetype from any slot by any command.
  
  I don't see how it doesn't know anything about it, given that it
  requires me to list a full package atom in package.provided.  So it
  always knows which version should be considered as being provided.
  
  Yes. freetype version 1. So if a package depends on freetype version 1,
  portage assumes, the dep is already installed.
  It does not know, where it is installed, or what files it installed. So
  it has to assume, that an emerge of freetype-2 actually could overwrite
  some of your freetype-1 files. Therefore it should not install
  freetype-2 with any command, if you have any version of freetype in
  package.provided.
 
 I disagree.  A slotted package is practically two different packages
 that simply share the same name.  If one slot is assumed as being
 provided, then that slot should have no effect on the other ones.

You cannot provide a slot - you provide a package - freetype in this case. A 
slot is a gentoo specific thing. If you provide a package, you lose the 
advantages of portage. One of them being slots.

 With your argument, portage should not install *any* packages at all if
 there's even a single entry in package.provided, because it doesn't know
 what that package installs and therefore *any other* package could
 results in conflicts.

Say, you had freetype-2.x in your package provided and for some reason you 
configured it to install to /usr/include/freetype, /usr/lib/freetype and so on.
What should emerge do, if you now emerge freetype:1? Install it and overwrite 
your provided package? I only flipped versions here, because configuring 
freetype:1 to install to */freetype-2 sounds a bit strange :)
If you tell portage I care for freetype myself, then you have to deal with 
it. If you really need freetype:2 together with freetype:1, you have to 
provide freetype:2 also. Only you know, how to configure it, so it does not 
conflict with your freetype:1

Best,
Michael

Re: [gentoo-user] Re: package.provided messes up emerging of package slots?

[Alan McKinnon]

On Mon, 12 Sep 2011 23:48:01 +0300
Nikos Chantziaras rea...@arcor.de wrote:

  If you provide xyz-1.2.3 then portage does not know what *you* did
  to achieve that and makes no attempt to deal with it at all. You are
  expected to completely 100% deal with all of xyz, including all
  slots. man 5 portage mentions that the version number is there in
  package.provided so that portage can alert you if some other package
  has a dep on a version of xyz you did not provide.  
 
 Yes, on a *version*, not on a *slot*, which is in effect a different 
 package but simply using the same name.

I can't explain that (and reading the portage sources is not something
that fills me with joy).

I can think up a few possibilities ranging from the .provided code
predates slots and has never been touched since all the way up to there
being some real conflict you and I don't know about.


 
 
  Seen in that light, the behaviour is indeed sensible, just not
  consistent if you haven't read the docs yet. I don't think it's
  wise to try and change portage's behaviour with this, as Michael
  said in another sub-thread portage has no idea what you did so it
  can't even try to take control of different slots for fear it might
  clobber all your manual hard work  
 
 As I mentioned in my other post, portage should stop working
 altogether then, because conflicts can arise with any other package.
 But portage *does* allows me to install package foo if I have
 bar-1.0 listed in package.provided.  For the same reason, it should
 allow me install foo:2 if I have a foo in package.provided that
 belongs to the foo:1 slot.

If portage tries to clobber a file you provided, then portage will see
it and collision-protect will do it's job. If you clobber an existing
file while installing something you provided, well that's your fault
and you should have paid attention. So I don't think the foo|bar
scenario you describe is anything worth worrying about. 

Maybe it really is just a case of You provided xyz, you will
therefore provide everything about xyz, even slots. I know that's the
starting position I would take if I were Zac.


-- 
Alan McKinnnon
alan.mckin...@gmail.com

[gentoo-user] Re: package.provided messes up emerging of package slots?

[Nikos Chantziaras]

On 09/13/2011 12:18 AM, Michael Schreckenbauer wrote:

On Monday, 12. September 2011 23:42:30 Nikos Chantziaras wrote:

On 09/12/2011 10:02 PM, Michael Schreckenbauer wrote:

On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote:

On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote:

On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote:

On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote:

On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote:

In my /etc/portage/profile/package.provided, I have this:
   media-libs/freetype-1.4_pre20080316-r2

When I try to emerge freetype however, instead of emerging the
newer

version, I get:
   $ emerge freetype

   WARNING: A requested package will not be merged
   because
   it is
   listed

   in package.provided:
 freetype pulled in by 'args'

   Nothing to merge; would you like to auto-clean
   packages?
   [Yes/No]

Trying emerge freetype:2 also won't work.  The only only to
emerge
it
seems is by using the whole version (emerge
=freetype-2.4.6).
Is
this
a bug?


At least it's inconsistent. I would expect that the emerge with
complete version also fails.


It's slotted, so it shouldn't fail.  Freetype 1 and 2 can be
installed
at the same time.


Yes, that's true for the packages provided by portage. portage does
not
know anything about the freetype you provide, so it shouldn't
install
any freetype from any slot by any command.


I don't see how it doesn't know anything about it, given that it
requires me to list a full package atom in package.provided.  So it
always knows which version should be considered as being provided.


Yes. freetype version 1. So if a package depends on freetype version 1,
portage assumes, the dep is already installed.
It does not know, where it is installed, or what files it installed. So
it has to assume, that an emerge of freetype-2 actually could overwrite
some of your freetype-1 files. Therefore it should not install
freetype-2 with any command, if you have any version of freetype in
package.provided.


I disagree.  A slotted package is practically two different packages
that simply share the same name.  If one slot is assumed as being
provided, then that slot should have no effect on the other ones.


You cannot provide a slot - you provide a package - freetype in this case. A
slot is a gentoo specific thing.


So is package.provided :-)



With your argument, portage should not install *any* packages at all if
there's even a single entry in package.provided, because it doesn't know
what that package installs and therefore *any other* package could
results in conflicts.


Say, you had freetype-2.x in your package provided and for some reason you
configured it to install to /usr/include/freetype, /usr/lib/freetype and so on.
What should emerge do, if you now emerge freetype:1? Install it and overwrite
your provided package?


Yes.  It should do exactly that.  Because of lack of information, it 
should assume that I know what I'm doing.


Fortunately, it does exactly that :-)  The original point of my post is 
why it works with emerge foo-version but not with emerge foo:slot.

Re: [gentoo-user] Re: package.provided messes up emerging of package slots?

[Michael Schreckenbauer]

On Tuesday, 13. September 2011 01:11:39 Nikos Chantziaras wrote:
 On 09/13/2011 12:18 AM, Michael Schreckenbauer wrote:
  On Monday, 12. September 2011 23:42:30 Nikos Chantziaras wrote:
  On 09/12/2011 10:02 PM, Michael Schreckenbauer wrote:
  On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote:
  On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote:
  On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote:
  On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote:
  On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote:
  In my /etc/portage/profile/package.provided, I have this:
 media-libs/freetype-1.4_pre20080316-r2
  
  When I try to emerge freetype however, instead of emerging
  the
  newer
  
  version, I get:
 $ emerge freetype
 
 WARNING: A requested package will not be
 merged
 because
 it is
 listed
 
 in package.provided:
   freetype pulled in by 'args'
 
 Nothing to merge; would you like to
 auto-clean
 packages?
 [Yes/No]
  
  Trying emerge freetype:2 also won't work.  The only only
  to
  emerge
  it
  seems is by using the whole version (emerge
  =freetype-2.4.6).
  Is
  this
  a bug?
  
  At least it's inconsistent. I would expect that the emerge
  with
  complete version also fails.
  
  It's slotted, so it shouldn't fail.  Freetype 1 and 2 can be
  installed
  at the same time.
  
  Yes, that's true for the packages provided by portage. portage
  does
  not
  know anything about the freetype you provide, so it shouldn't
  install
  any freetype from any slot by any command.
  
  I don't see how it doesn't know anything about it, given that it
  requires me to list a full package atom in package.provided.  So
  it
  always knows which version should be considered as being provided.
  
  Yes. freetype version 1. So if a package depends on freetype version
  1,
  portage assumes, the dep is already installed.
  It does not know, where it is installed, or what files it installed.
  So
  it has to assume, that an emerge of freetype-2 actually could
  overwrite
  some of your freetype-1 files. Therefore it should not install
  freetype-2 with any command, if you have any version of freetype in
  package.provided.
  
  I disagree.  A slotted package is practically two different packages
  that simply share the same name.  If one slot is assumed as being
  provided, then that slot should have no effect on the other ones.
  
  You cannot provide a slot - you provide a package - freetype in this
  case. A slot is a gentoo specific thing.
 
 So is package.provided :-)

Of course :) Point is, you provide a package from the outside world, you tell 
that portage via package.provided. In the outside world, there is no slot. So 
you cannot provide slots.

  With your argument, portage should not install *any* packages at all
  if
  there's even a single entry in package.provided, because it doesn't
  know
  what that package installs and therefore *any other* package could
  results in conflicts.
  
  Say, you had freetype-2.x in your package provided and for some reason
  you configured it to install to /usr/include/freetype,
  /usr/lib/freetype and so on. What should emerge do, if you now emerge
  freetype:1? Install it and overwrite your provided package?
 
 Yes.  It should do exactly that.  Because of lack of information, it
 should assume that I know what I'm doing.
 
 Fortunately, it does exactly that :-)  The original point of my post is
 why it works with emerge foo-version but not with emerge foo:slot.

Yes, it does that. In my opinion, that behaviour is not correct.

I think, you are abusing package.provided for something, that should be 
handled by a local overlay with patched freetype-ebuilds.

Best,
Michael

[gentoo-user] Re: package.provided messes up emerging of package slots?

[Nikos Chantziaras]

On 09/13/2011 01:26 AM, Michael Schreckenbauer wrote:

On Tuesday, 13. September 2011 01:11:39 Nikos Chantziaras wrote:

[...]
You cannot provide a slot - you provide a package - freetype in this
case. A slot is a gentoo specific thing.


So is package.provided :-)


Of course :) Point is, you provide a package from the outside world, you tell
that portage via package.provided. In the outside world, there is no slot. So
you cannot provide slots.


I think Alan actually provided a more correct POV, namely that 
package.provided was never updated to consider slots.  If in the 
outside world there are no slots, then portage shouldn't have 
introduced that feature in the first place.  But it did, and the 
package.provided mechanism was never updated.




Say, you had freetype-2.x in your package provided and for some reason
you configured it to install to /usr/include/freetype,
/usr/lib/freetype and so on. What should emerge do, if you now emerge
freetype:1? Install it and overwrite your provided package?


Yes.  It should do exactly that.  Because of lack of information, it
should assume that I know what I'm doing.

Fortunately, it does exactly that :-)  The original point of my post is
why it works with emerge foo-version but not with emerge foo:slot.


Yes, it does that. In my opinion, that behaviour is not correct.

I think, you are abusing package.provided for something, that should be
handled by a local overlay with patched freetype-ebuilds.


I'm pretty sure you know very well by now that forking the portage tree 
isn't a Gentooer's idea of a great time ;-)  We use Gentoo's tools to 
their fullest in order to lower burden and overhead, not raise it.


Forking my own ebuild means I need to maintain it; forever and ever. 
And stuff like that will keep piling up over time, leading to a big, 
magnificent pile of unmaintainable mess, leading to a bad experience and 
the question of I use Gentoo in the first place if all it will give me 
is annoyance and stress.


On the other hand, if a single line in package.provided does the job 
just as well, oh hell, I'm going for that one instead.

Re: [gentoo-user] Re: package.provided syntax

[Rumen Yotov]

On Monday 06 March 2006 21:09, Harry Putnam wrote:
 Zac Medico [EMAIL PROTECTED] writes:
rsnapshot-1.2.2
bacula-1.48.5
cvs-emacs-24
 
  The example for package.provided syntax in `man portage` shows categories
  like this:
 
  app-backup/rsnapshot-1.2.2
  app-backup/bacula-1.48.5
  app-editors/emacs-cvs-24

 Ok, I'm a little gun shy to post this now but I'm still seeing
 somethign screwy.

 cat /etc/portage/package.provided
 app-backup/rsnapshot-1.2.2
 app-backup/bacula-1.48.5
 app-editors/emacs-cvs-24

 emerge -vp app-editors/emacs-cvs:
   These are the packages that would be merged, in order:
   Calculating dependencies... done!
 [ebuild U ] app-editors/emacs-cvs-22.0.50-r1 [22.0.50] USE=X gif
 gtk jpeg nls png spell -Xaw3d -tiff 0 kB


 Man portage mentions a version must be included:
  Format:
  - comments begin with #
  - one DEPEND atom per line
  - relational operators are not allowed
  - must include a version

 It also says:
   . . . . . . Portage will  not  attempt  to  update  a
   package  that  is  listed  here  unless  another  package
   explicitly requires a version that is newer than what has
   been  listed.

 So I thought maybe it didn't like my fake version so changed it to:

app-editors/emacs-cvs-22.0.50-r1
 And I still get the same output.

 Removing the -r1 since its not really emacs versioning and I still get
 the same output...
 Something is making emerge ignore this package.provided
Hi,
In my case (using it a little but think it works) the file is in other dir:
# cat /etc/portage/profile/package.provided
app-admin/fam-2.7.0-r2
Only now i see that forgot to change this (left from fam-- gamin conversion).
HTH.Rumen


pgpigpRKlY2YJ.pgp
Description: PGP signature

Re: [gentoo-user] Re: package.provided syntax

[Zac Medico]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Harry Putnam wrote:
 The example for package.provided syntax in `man portage` shows categories 
 like this:

 app-backup/rsnapshot-1.2.2
 app-backup/bacula-1.48.5
 app-editors/emacs-cvs-24
 
 Ok, I'm a little gun shy to post this now but I'm still seeing
 somethign screwy.
 
 cat /etc/portage/package.provided

Oops, package.provided goes in /etc/portage/profile/ (it's an override for 
/etc/make.profile).  That's probably a common mistake.


 app-backup/rsnapshot-1.2.2
 app-backup/bacula-1.48.5
 app-editors/emacs-cvs-24
 
 emerge -vp app-editors/emacs-cvs:
   These are the packages that would be merged, in order:
   Calculating dependencies... done!
 [ebuild U ] app-editors/emacs-cvs-22.0.50-r1 [22.0.50] USE=X gif
 gtk jpeg nls png spell -Xaw3d -tiff 0 kB

Hmm, the emerge output indicates that app-editors/emacs-cvs-22.0.50 is 
installed (managed by portage).  Normally package.provided is used for packages 
that aren't managed by portage.  Now I'm not sure what you want to accomplish.

Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEDT/V/ejvha5XGaMRAuY5AJ9zVGlkeL+bjPhaA52m4d5edJQWlwCg44l7
x4iYA2CCaPYiLxTkqp7y29g=
=otXv
-END PGP SIGNATURE-
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: package.provided syntax

[Harry Putnam]

Rumen Yotov [EMAIL PROTECTED] writes:


[...]

 Hi,
 In my case (using it a little but think it works) the file is in other dir:
 # cat /etc/portage/profile/package.provided
 app-admin/fam-2.7.0-r2

Zac Medico [EMAIL PROTECTED] writes:
 Oops, package.provided goes in /etc/portage/profile/ (it's an
 override for /etc/make.profile).  That's probably a common mistake.

Thanks posters... yup, no wonder it was being ignored eh?
All better now.

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: package.provided syntax

[Harry Putnam]

Dave Nebinger [EMAIL PROTECTED] writes:

 Harry Putnam wrote:
 in package.provided:
   cvs-emacs-24

 [snip]

 emerge -vuDp app-editors/emacs-cvs

 Don't you see that cvs-emacs is not the same as emacs-cvs, or was this
 just a typo on your part?

Gack.. not a typo a braino

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: package.provided syntax

[Harry Putnam]

Zac Medico [EMAIL PROTECTED] writes:

 app-backup/rsnapshot-1.2.2
 app-backup/bacula-1.48.5
 app-editors/emacs-cvs-24

Haa there it is 
Another dopey message was sent before I saw this, and the real sorry
part is that I've been caught by this before and not too long ago.

I've recently done a full reinstall from scratch and when I redid that
part I forgot about it again...

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: package.provided syntax

[Harry Putnam]

Zac Medico [EMAIL PROTECTED] writes:

   rsnapshot-1.2.2
   bacula-1.48.5
   cvs-emacs-24

 The example for package.provided syntax in `man portage` shows categories 
 like this:

 app-backup/rsnapshot-1.2.2
 app-backup/bacula-1.48.5
 app-editors/emacs-cvs-24

Ok, I'm a little gun shy to post this now but I'm still seeing
somethign screwy.

cat /etc/portage/package.provided
app-backup/rsnapshot-1.2.2
app-backup/bacula-1.48.5
app-editors/emacs-cvs-24

emerge -vp app-editors/emacs-cvs:
  These are the packages that would be merged, in order:
  Calculating dependencies... done!
[ebuild U ] app-editors/emacs-cvs-22.0.50-r1 [22.0.50] USE=X gif
gtk jpeg nls png spell -Xaw3d -tiff 0 kB


Man portage mentions a version must be included:
 Format:
 - comments begin with #
 - one DEPEND atom per line
 - relational operators are not allowed
 - must include a version

It also says:
  . . . . . . Portage will  not  attempt  to  update  a
  package  that  is  listed  here  unless  another  package
  explicitly requires a version that is newer than what has
  been  listed.

So I thought maybe it didn't like my fake version so changed it to:

   app-editors/emacs-cvs-22.0.50-r1
And I still get the same output.  

Removing the -r1 since its not really emacs versioning and I still get
the same output...
Something is making emerge ignore this package.provided

-- 
gentoo-user@gentoo.org mailing list