upgrading udev-171 to udev-180 - updating a quite old Gentoo

guffegris · Tux's lil' helper Joined: 06 Feb 2017 Posts: 142

Hi,

I am trying to upgrade an old installation that has not been updated for a long time, so I want to take it in small steps. I want to upgrade from udev-171 to udev-180, so I downloaded udev-180.ebuild to my local portage overlay, and I ran ebuild udev-180.ebuild manifest with succes, so my next step was to try to emege it:

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

The tilde ~ just means that version is masked.

You aren't kidding about being "old." The oldest version of kmod in the current portage tree is kmod-22, and the oldest version of udev in the current portage tree is udev-215. Maybe complicating (and maybe simplifying), try replacing udev with eudev at some point.

My first reaction when looking at your report was "is this system looking at an overlay?" Now I wonder if it is looking at an aged portage tree. Have you read any of those 38 enews items yet?

khayyam

xaviermiller · Posted: Wed Mar 01, 2017 2:23 pm Post subject:

... and read the 38 news items (eselect news read)

_________________
Kind regards,
Xavier Miller

NeddySeagoon · Posted: Wed Mar 01, 2017 3:23 pm Post subject:

guffegris,

You are trying to jump a chasm is several small jumps :)

The path of least resistance is a new install. It will be faster in the long term.
Updating will give you a Gentoo educational experience that you can get no other way.

Go with khayyams advice.
You will have to do incremental steps because things like gcc and glibc are mutual blockers.
You update one as far as you can, then the other ... several times.

You may find you need some binary packages to get started. Thats OK, since you will rebuild them later for yourself.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

guffegris · Tux's lil' helper Joined: 06 Feb 2017 Posts: 142

Hi everybody! - and thanks for all the answers! :-)

OK, so the tilde means masked! - that make sence! - but then the problem is that I can't find where it it masked; it is not in my package.mask, or any other place that I could think of, and a find -name "*.mask" -exec grep kmod {} \¸did neither give anything - any hints where to look?

NeddySeagoon:
Yes, I know that a fresh install will probably be easier, but I am not going that way. I will accept the challenge and see if I can make the update for several reasons; first I love my old Gentoo system, and by doing the update in small steps I can avoid to go to gnome 3 which I don't like, and second my thought was that by doing the update I would learn quite i bit - exactly as you say! :-)

- I have already learnt quite a bit, and I am actually documenting my experiences for myself for later use. I am pretty sure that the hours spent documenting now will come in handy at a later time.

So following khayyams advice I should start by updating the package system? - that must be portage I believe? - and then later upgrade gcc, glibc, binutils and stuff like that, - it that correct? - I think that portage should not be so hard, as I started out this quest by updating portage quite recently. I am on version 2.3.0 now:

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

Masking is done with a tilde as part of a KEYWORDS variable

Just to pick an example, cd to /usr/portage/sys-kernel/gentoo-sources

You will find a few *.ebuild files

grep KEYWORDS /usr/portage/sys-kernel/gentoo-sources/*ebuild

So, for kmod, somewhere along the way (looks like the year 2012 or so) there was a package of kmod with a version 4, kmod-4, and a corresponding kmod-4.ebuild.

My point of reference on this is https://archives.gentoo.org/gentoo-commits/message/b7da50f6a48cb5b52c636a5a0eb0128d

NeddySeagoon · Posted: Thu Mar 02, 2017 8:33 am Post subject:

guffegris,

Gentoo has several levels of stability. By default, you get stable. Indicated by no tilde. Then there are the testing versions, indicated mith the tilde.
Last but not least there are "live" versions, indicated by veh version number 9999. These are not keyworded at all. They are called live, as the ebuilds pull from the upstream projects as it is when you run emerge.

Once you get portage up to date, which may require a more up to date python than you have, you can rebuild your toolchain.
There is a script for that. Run

guffegris · Tux's lil' helper Joined: 06 Feb 2017 Posts: 142

Hi guys,

OK, I have been doing a bit of reading based on your answers, so now I think that I have got it! - From my understanding, the tilde is used in front of a keyword (which usually describe an architecture like x86, sparc or something like that). When the tilde is present it tells that this is code that has not yet marked as stable, but it is trusted to work, it just needs more testing. Per default portage will only emerge stable code, so if I want to use the new code which hasn't been marked stable yet, I will have to tell portage that the bleeding edge code is OK to use by adding an entry in package.accept_keywords. In the present case one could imagine an entry like this:

=udev-180 ~kmod

this tell portage that it will be OK to emerge kmod-4 even though it is not marked stable - not that it matters, for I can't find the ebuild in the attic, but the principle is all right, - correct me if I am wrong.

In this line:

emerge: there are no ebuilds to satisfy "~sys-apps/kmod-4".

the tilde is just an information telling me that kmod version 4 has not yet been marked as stable, so I have to use it with caution, - but on the other hand I have no choise, as kmod in the exact version of 4 is needed to do this emerge. Am I right? :-)

---

Homework - why emerge -1 for gcc ?

Well, - here the pupil actually have a fighting chance, for I believe that I already did that study! ;-)

- This is as I understand it:

There is a set called @world (realized by the file /var/lib/portage/world) which tells portage what packets the user actually want have to exist in his concept of "the world" - i.e. the packets that the user directly installed, for example gnome, firefox, tuxracer and so on. Every time the user emerges such a packet portage adds it to @world. This way portage knows that if a packet is in the worldset, it should never unmerge the packet again - even if this packet no longer has any dependencies that demands it, - simply becouse this is something the user wants.

Now, if I were to emerge for instance sys-apps/kmod-4 in the hope to easier get udev uddated, then kmod-4 would be added to @world, but that is not a good idea as I have no interest in having kmod-4 in my system if udev-180 should be unmerged or updated. The way to get arround this, is to let portage know that it should not put kmod-4 in the worldset, and that is done with a command like this:

emerge --oneshot kmod-4

Oneshot tell portage that I only want kmod-4 one time - not forever. likewise the command:

emerge -1 =sys-devel/gcc-4.7.4

here the -1 is just the short name for --oneshot, which make sence, as this is the same kind of systemwork as in the kmod-4 example. Correct me if I am wrong.

Unfortunately there is a tendency to forget the -1 option - at least for me there is, and that leads to a certain "polution" of the worldfile, as more and more packets that I don't specifically want myself enters the world set, and that makes system updates harder, as emerge can't unmerge the packets at will. That was actually what started this tread, becourse as part of getting a better understanding of what was actually needed in my heavily polluted worldfile I tried to run emerge -p --depclean @world, but portage would not complete the command due to inconsistences, therefore I tried to update just as much as needed to run the command so I could get the info. That led me to the updating of udev to version 180 - and the rest you know... :-)

I have updated portage to version 2.3.3, so I believe that at least portage is up to date by now, so the next step must be the toolchain, but I will wait till I hear your answers.

Thank a lot for you great support! - I am clearly learning quite a bit here! :-)

NeddySeagoon · Posted: Thu Mar 02, 2017 8:37 pm Post subject:

guffegris,

emerge --sync, if you haven't done that already then run that stage1 script I posted about earlier.
Its good to do incremental updates but only when you need to.
Portage will tell you all about it.

I don't expect /usr/portage/scripts/bootstrap.sh to work, but you never know.
Report problems here.

Full marks for your homework assignment.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

Unmasking, or "keywording" is done with reference only to the package being allowed. Portage doesn't care why you are allowing this package. You can allow it because another package depends on a keyworded package, or you can allow an unstable "keyworded" package just because you feel like it.

So, an entry like "=udev-180 ~kmod" is incorrect, it refers to two different packages.

A correct entry can take various forms.

One form allows the "unstable" version, no matter what. Using ~x86 as the allowed keyword, the entry would be
"sys-apps/kmod ~x86"

Another form allows only one specified version level. An entry of this form includes an equals sign.
"=sys-apps/kmod-4 ~x86"

guffegris · Tux's lil' helper Joined: 06 Feb 2017 Posts: 142

cboldt:

OK, I get your point! - I mistook kmod for a keyword, but it is in fact the name of a packet or a use! - by allowing unstable for kmod as you demonstrate it, udev can pull in the unstable kmod-4 without portage complaining! - Thanks! :-)

NeddySeagoon:

OK, I have done the sync and then I ran the the bootstrapscript as I was told. The first part where it emerged portage again ran not so surprisingly without any problems, but after that when it tried to install gcc and so on, emerge gave up due to slot conflicts:

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

I'm so used to it that I don't give it a second thought, but now that you mention it, having USE flags and package names exactly the same certainly creates a risk of confusion. kmod is both a USE flag, and a package name. That is not the only instance either.

At the same time, using the same name for both a package and a USE flag is a very handy shorthand.

udev CAN use kmod, but it can also be built so it does NOT use kmod. The user decides which of those options to follow by setting a USE flag that applies to udev. This is similar to "keywording," but is in a file that I will refer to as "package.use."

Every package has default USE flags, some of which are optional but still turned on by default. Entries in "package.use" can modify the defaults. If you wanted to build udev WITHOUT kmod, you would put an entry in "package.use"

guffegris · Tux's lil' helper Joined: 06 Feb 2017 Posts: 142

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

You could install eix, it gives the short DESCRIPTION (all caps, because that is a variable name) that is provided in the ebuild for that package. Or skip eix and just look in the ebuild ...

khayyam · Posted: Fri Mar 03, 2017 10:15 am Post subject:

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

Oh, what you describe brings up another question too. You might know what a package is or does, or find that out, but that doesn't always answer questions about what a USE flag does.

I use `ufed` for that purpose, or more often these days, read the ebuild and see how a USE flag is applied.

If ou are online, check https://www.gentoo.org/support/use-flags/

khayyam · Posted: Fri Mar 03, 2017 11:13 am Post subject:

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

Thanks for that. I'm sure I have used that in the past, even though most of my equery commands are "belongs" and "depends" I'd say the odds of me remembering `equery u` he next time I am curious or need to know about a USE flag are about 50-50. So many ways to skin the cat. My habitual go-to is `ufed`, and that just for viewing, I never use ufed to actually edit USE flags ;-)

guffegris · Tux's lil' helper Joined: 06 Feb 2017 Posts: 142

Thanks guys! - that was just what I needed! - I can see that there more than one way to skin a cat, but in common I think that eix <package/name> is an easy way to go! - it gives the short describtion, and even a url to the homepage of the packet where further information can be found! :-)

Now back to the update...

NeddySeagoon:

I have now completed the bootstrap script as I was told. To carry it through I did:

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

The news ought to clear itself, but since it hasn't, `eselect news purge` will rid you of the unnecessary reminders.

NeddySeagoon · Posted: Fri Mar 03, 2017 6:05 pm Post subject:

guffegris,

I was expecting gcc and glibc to need to do several iterative updates. It didn't happen. That makes life easy.

Now you have an up to date toolchain, use gcc-config to select your newest gcc. It should be 4.9.4
That's newest stable, as of my post above.

Contine with

guffegris · Tux's lil' helper Joined: 06 Feb 2017 Posts: 142

Hi again,

Well, something here is not quite right; becourse as you say:

guffegris · Tux's lil' helper Joined: 06 Feb 2017 Posts: 142

A little more information: I just tried a test emerge of glibc with this result:

NeddySeagoon · Posted: Sat Mar 04, 2017 8:50 am Post subject:

guffegris,

This is where its going to grow arms and legs and things are going to get broken.

Your old dev-libs/boost is keeping sys-libs/glibc at an old version.
There are two fixes, update dev-libs/boost which will probably upset a lock of packages that depend on it or remove dev-libs/boost, which will break all the things that depend on it.
boost is a core C++ library, so most of your C++ would be broken. Lets come back to that.

Your emerge -p gcc looks promising. glibc isn't mentioned. Notice that [ebuild NS ]. Thats a new slotted version, so it installs at the same time as your other versions.
That makes it harmless to go ahead with