Mailing List Archive

Re: What is the best way forward? - Update 1
On 2/25/21 5:31 PM, Grant Taylor wrote:
> 10 have git switch to the next day
> 20 emerge -aDUN @world
> 30 assess / deal with masked packages
> 40 goto 10
>
> It /looks/ like things are working.

This method is working.

I have managed to successfully update from 2020-03-24 to 2020-05-29 in
one day increments.

I'm starting to see some oddities, like a given version of gimp blocking
itself. Unmerging and re-emerging solved that. So I'm going to let the
system spend 12 hours and do an emerge -DUNe @world && emerge --depclean
--verbose n && revdep-rebuild, reboot, and continue with 2020-06-01.

I have run into a few problems where emerge can't download files. So
I'm finding them online, downloading them, and saving them to
/usr/portage/distfiles.

I have had a couple things (really old kernel source still installed)
that I needed to find the ebuild files for. I added them to my local
repository.

I did have an ancient package, ncpfs, that was blocking things. Since I
didn't need it, I have unmerged it. If / when I need it in the future,
I'll deal with it then.



--
Grant. . . .
unix || die
Re: What is the best way forward? - Update 1 [ In reply to ]
On Fri, 26 Feb 2021 11:44:12 -0700, Grant Taylor wrote:

> I have run into a few problems where emerge can't download files. So
> I'm finding them online, downloading them, and saving them to
> /usr/portage/distfiles.

Ah yes, I hadn't thought about the mirrors being too up to date.

> I have had a couple things (really old kernel source still installed)
> that I needed to find the ebuild files for. I added them to my local
> repository.

If the packages are installed, the ebuilds are in var/db/pkg. The kernel
shouldn't be a problem, I would expect you to be able to jump straight to
the current version, although you may prefer to recompile it once you are
fully up to date on the toolchain.


--
Neil Bothwick

Crash: (v.) to terminate a program in the usual fashion, i.e. by locking
up the computer or setting fire to the printer. (n.) the process of such
termination.
Re: What is the best way forward? - Update 1 [ In reply to ]
On 2/26/21 12:50 PM, Neil Bothwick wrote:
> Ah yes, I hadn't thought about the mirrors being too up to date.

There's also issue with older packages being installed. E.g. I have an
older kernel source (4.14.127) that I'm keeping around for various
reasons. I've found that the Gentoo repo / portage removes older ebuild
files. So, I've had to source them and add them to my local repo.

Even putting the old ebuilds into my local repo is entertaining because
repoman / ebuild fail to download the source files b/c the mirrors have
updated. Hence finding files and putting them in distfiles.

> If the packages are installed, the ebuilds are in var/db/pkg.

The package (distribution files) for the version that is installed are
in distfiles. But that does little for an ebuild that's looking for a
newer version that's no longer on the expected mirrors.

> The kernel shouldn't be a problem, I would expect you to be able
> to jump straight to the current version, although you may prefer to
> recompile it once you are fully up to date on the toolchain.

This system has both Open vSwitch and OpenZFS, so I'm loath to allow
automation to change the kernel version. That will be a problem for
future me to deal with manually.



--
Grant. . . .
unix || die
Re: What is the best way forward? - Update 1 [ In reply to ]
On Fri, 26 Feb 2021 at 23:30, Grant Taylor
<gtaylor@gentoo.tnetconsulting.net> wrote:
> > If the packages are installed, the ebuilds are in var/db/pkg.
>
> The package (distribution files) for the version that is installed are
> in distfiles. But that does little for an ebuild that's looking for a
> newer version that's no longer on the expected mirrors.

I'm not sure what you're saying here, but the ebuild files of the
installed packages are in /var/db/pkg

Regards,
Arve
Re: What is the best way forward? - Update 1 [ In reply to ]
On 2/26/21 11:55 PM, Arve Barsnes wrote:
> I'm not sure what you're saying here, but the ebuild files of the
> installed packages are in /var/db/pkg

Hum.

Today I Learned...

The ebuild and what looks like additional metadata files are in the
/var/db/pkg directory tree. But the source files aren't in the tree.
At least not for the example package I looked at.

Find across the /var/db/pkg tree does not find any tar files either.



--
Grant. . . .
unix || die
Re: What is the best way forward? - Update 1 [ In reply to ]
On Sat, 27 Feb 2021 00:47:04 -0700, Grant Taylor wrote:

> The ebuild and what looks like additional metadata files are in the
> /var/db/pkg directory tree. But the source files aren't in the tree.
> At least not for the example package I looked at.

That's right, the source files are in $DISTDIR, unless you have cleaned
it. /var/db/pkg contains all the information portage needs about the
installed software.


--
Neil Bothwick

Where do forest rangers go to "get away from it all?"
Re: What is the best way forward? - Update 1 [ In reply to ]
On Saturday, 27 February 2021 08:34:02 GMT Neil Bothwick wrote:
> On Sat, 27 Feb 2021 00:47:04 -0700, Grant Taylor wrote:
> > The ebuild and what looks like additional metadata files are in the
> > /var/db/pkg directory tree. But the source files aren't in the tree.
> > At least not for the example package I looked at.
>
> That's right, the source files are in $DISTDIR, unless you have cleaned
> it. /var/db/pkg contains all the information portage needs about the
> installed software.

$ emerge --info | grep DISTDIR

will show if the source files directory is in the old /usr/portage/distfiles,
or the new default of /var/cache/distfiles, or some custom location the user
has specified in /etc/portage/make.conf.
Re: What is the best way forward? - Update 1 [ In reply to ]
On Sat, 27 Feb 2021 08:59:08 +0000, Michael wrote:

> > That's right, the source files are in $DISTDIR, unless you have
> > cleaned it. /var/db/pkg contains all the information portage needs
> > about the installed software.
>
> $ emerge --info | grep DISTDIR
>
> will show if the source files directory is in the old
> /usr/portage/distfiles, or the new default of /var/cache/distfiles, or
> some custom location the user has specified in /etc/portage/make.conf.

Or the somewhat faster

$ portageq distdir :)


--
Neil Bothwick

Nixon's Principal: If 2 wrongs don't make a right, try 3.