Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: AMD64

Emerge Ignores Newer Ebuilds If Older Given In Package.Provided

 

 

Gentoo amd64 RSS feed   Index | Next | Previous | View Threaded


frank.peters at comcast

May 26, 2010, 12:08 PM

Post #1 of 8 (1448 views)
Permalink
Emerge Ignores Newer Ebuilds If Older Given In Package.Provided

I always thought that if an ebuild is newer than one listed in package.provided,
emerge should report this newer ebuild as an update. But that is not what
happens on my system.

For example, if I put media-sound/wavegain-1.2.6, which is an older version,
in my package.provided file, emerge -pvDu world does not indicate that a newer
version, media-sound/wavegain-1.2.8, is available. The only message is that
the package is listed in package provided and thus will not be emerged.

So on my system, the ebuild version given in package.provided seems to be
completely ignored.

I suspect that this is not correct. Should a bug report be filed?

Frank Peters


ken69267 at gmail

May 26, 2010, 1:21 PM

Post #2 of 8 (1405 views)
Permalink
Re: Emerge Ignores Newer Ebuilds If Older Given In Package.Provided [In reply to]

On Wed, 26 May 2010 15:08:13 -0400
Frank Peters <frank.peters [at] comcast> wrote:

> I suspect that this is not correct. Should a bug report be filed?
>
> Frank Peters
>
from man portage:

package.provided
[snip some stuff]
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.
Attachments: signature.asc (0.19 KB)


frank.peters at comcast

May 26, 2010, 3:27 PM

Post #3 of 8 (1412 views)
Permalink
Re: Emerge Ignores Newer Ebuilds If Older Given In Package.Provided [In reply to]

On Wed, 26 May 2010 16:21:14 -0400
Kenneth Prugh <ken69267 [at] gmail> wrote:

> from man portage:
>
> package.provided
> [snip some stuff]
> 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.

I thought that the purpose of package.provided was broader, but
I guess that it serves only to record dependencies for other packages.

Thanks for clearing that up.

Frank Peters


chemoelectric at chemoelectric

May 26, 2010, 4:25 PM

Post #4 of 8 (1420 views)
Permalink
Re: Emerge Ignores Newer Ebuilds If Older Given In Package.Provided [In reply to]

Frank Peters <frank.peters [at] comcast> skribis:
> On Wed, 26 May 2010 16:21:14 -0400
> Kenneth Prugh <ken69267 [at] gmail> wrote:
>
> > from man portage:
> >
> > package.provided
> > [snip some stuff]
> > 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.
>
> I thought that the purpose of package.provided was broader, but
> I guess that it serves only to record dependencies for other packages.

An "phony" ebuild in an overlay would do what you wanted, I think.


frank.peters at comcast

May 26, 2010, 5:35 PM

Post #5 of 8 (1412 views)
Permalink
Re: Emerge Ignores Newer Ebuilds If Older Given In Package.Provided [In reply to]

On Wed, 26 May 2010 18:25:52 -0500
Barry Schwartz <chemoelectric [at] chemoelectric> wrote:

>
> An "phony" ebuild in an overlay would do what you wanted, I think.
>
>

Maybe. I have not tried it.

I don't want to be overly critical of Gentoo (after all, it's the best
thing that's happened to my Linux computing universe in a long while), but
it seems that package.provided needs some extra capability.

There are some requests on bugs.gentoo.org that package.provided be
extended in various ways. In my opinion, package.provided should accomplish
just what the name implies. It should indicate that the Gentoo user
has compiled his own version of an ebuild (for whatever reason) and
if a newer ebuild exists, regardless of dependencies, this should be
indicated to the user (as it is with a normally emerged ebuild).

These are just my opinions. Whatever course of action the Gentoo
developers take is fine with me. Gentoo has improved my Linux experience
so much that it's hard to find any complaint.

Frank Peters


chemoelectric at chemoelectric

May 26, 2010, 6:25 PM

Post #6 of 8 (1408 views)
Permalink
Re: Emerge Ignores Newer Ebuilds If Older Given In Package.Provided [In reply to]

Frank Peters <frank.peters [at] comcast> skribis:
> On Wed, 26 May 2010 18:25:52 -0500
> Barry Schwartz <chemoelectric [at] chemoelectric> wrote:
>
> >
> > An "phony" ebuild in an overlay would do what you wanted, I think.
> >
> >
>
> Maybe. I have not tried it.
>
> I don't want to be overly critical of Gentoo (after all, it's the best
> thing that's happened to my Linux computing universe in a long while), but
> it seems that package.provided needs some extra capability.
>
> There are some requests on bugs.gentoo.org that package.provided be
> extended in various ways. In my opinion, package.provided should accomplish
> just what the name implies. It should indicate that the Gentoo user
> has compiled his own version of an ebuild (for whatever reason) and
> if a newer ebuild exists, regardless of dependencies, this should be
> indicated to the user (as it is with a normally emerged ebuild).
>
> These are just my opinions. Whatever course of action the Gentoo
> developers take is fine with me. Gentoo has improved my Linux experience
> so much that it's hard to find any complaint.

Paludis has a different approach to "provided" packages, but
personally I don't like it. Others may.


tanstaafl at libertytrek

May 27, 2010, 5:20 AM

Post #7 of 8 (1413 views)
Permalink
Re: Emerge Ignores Newer Ebuilds If Older Given In Package.Provided [In reply to]

On 2010-05-26 8:35 PM, Frank Peters wrote:
> There are some requests on bugs.gentoo.org that package.provided be
> extended in various ways. In my opinion, package.provided should
> accomplish just what the name implies. It should indicate that the
> Gentoo user has compiled his own version of an ebuild (for whatever
> reason) and if a newer ebuild exists, regardless of dependencies,
> this should be indicated to the user (as it is with a normally
> emerged ebuild).

Isn't that what your local overlay is for?

It sounds like you added a package that wasn't yet available in the main
gentoo repo, then later, an updated package became available in the main
gentoo repo, and you want that update to be applied?

That is what your local overlay is for - so you can add your own
packages, but updates from the main repo will still be available.


1i5t5.duncan at cox

May 27, 2010, 5:38 AM

Post #8 of 8 (1419 views)
Permalink
Re: Emerge Ignores Newer Ebuilds If Older Given In Package.Provided [In reply to]

Frank Peters posted on Wed, 26 May 2010 20:35:12 -0400 as excerpted:

> In my opinion, package.provided should accomplish just what the name
> implies. It should indicate that the Gentoo user has compiled his own
> version of an ebuild (for whatever reason) and if a newer ebuild exists,
> regardless of dependencies, this should be indicated to the user (as it
> is with a normally emerged ebuild).

You're right, there's some collision between the name and assumptions for
package.provided, and the assumptions for ordinary dependency resolution
vs. those for --deep. The package.provided functionality definitely
assumes that users do NOT want --deep functionality in regard to it.

FWIW, I prefer the current functionality, and actually, for the few
packages I place in package.provided, this is what I have, with the
obvious implications:

sys-kernel/gentoo-sources-2.6.999
mail-mta/ssmtp-999
mail-client/mailx-999
x11-apps/xsm-999
x11-terms/xterm-999

Given the 999 version numbers, it's pretty obvious that my intent is don't
EVER merge these. But actually, the kernel is the only one I actually
/do/ provide on my own. The others I simply don't want on my system, and
arguably they shouldn't be dependencies of anything I have installed, at
all.

I avoid busybox too, with this entry in the packages file since it's a
profile dependency:

-*sys-apps/busybox

I used to do similar with ssh, when I only had the single stand-alone
system, but now I use ssh to copy updates to my netbook, from the build
image on my main machine, so I obviously have it installed on both. But
why it's part of the default profile, I don't know, and by virtue of the
packages file, it wasn't, here, for many years.

But I can see that if people are installing a particular version manually,
and putting that specific version in package.provided to tell portage
about it, they'd expect to be notified on --update --deep when an update
came along, just as they'd normally be upgraded if it were installed
normally (except that they'd only be notified, not auto-upgraded, with
package.provided, because portage couldn't auto-remove the previous
version like it'd do if it installed the package, so that'd have to be
done manually).

--
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

Gentoo amd64 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.