Migrating from Layman to eselect-repository

[Zarhan]

Hello,

I just noticed that layman is slated for removal when I did an emerge --sync.

Are there some instructions on how to move to this new tool?

I do have my existing repos listed in /etc/portage/repos.conf/layman.conf and they get synced under /var/lib/layman.

Furthermore, what's the equivalent of layman -S (sync-all) after migration?

[alamahant]

Please see
https://wiki.gentoo.org/wiki/Eselect/Repository
I had one layman repo.I removed it and then added it via
eselect repository.
It was very easy.
As for syncing I fount that
eix-sync
works just fine for all.
I suppose you might first need to remove all layman repos and then re add them with eselect repository.
Thanks for letting me know about layman removal.

[Zarhan]

Was able to do this, but to me this indicates that there is *no* "migration" as such. It's more "make backup of configuration, uninstall layman, install eselect-repository, recreate configuration".

I also had only two repositories.

[Ionen]

Yeah, thing is that portage can already do most of what layman does, and it's just about configuring /etc/portage/repos.conf to sync additional repos alongside /var/db/repos/gentoo which itself won't be new to anyone.

And then eselect-repos is just a convenience tool to edit it for you and look at the available repository list (one thing that porrtage does not by itself).

I don't think(?) there's much to say in terms of migrating.

[szatox]

Well, there is not migration as such.
Layman and eselect-repo are 2 completely unrelated tools for adding overlays, so remove them from layman and either enable in eselect-repository (if they are already known and available) or add them.
It's a bit like migrating your documents from emacs to vim: how 'bout you just open them?


If the names of your overlays don't change, I'd expect emerge to keep recognizing them as the old repo in a new location, so it shouldn't break any dependencies/cause rebuilds.

[logrusx]

There's isn't a lot to migrate actually. It would be more work than removing them from layman and adding them from eselect-repository. Don't forget to delete /var/lib/layman btw. It looks like unmerging layman wouldn't remove it.

Best Regards,
Georgi

[c00l.wave]

I just migrated my system... Depending on the number of overlays it may take a few minutes but is almost straight forward, apart from some pitfalls caused by an unexpected default value for REMOTE_LIST_URI.

What I would recommend:

1. Install: emerge -av app-eselect/eselect-repository
2. Check/modify the configuration: $EDITOR /etc/eselect/repository.conf
   I would recommend to reconfigure REMOTE_LIST_URI to use the original list (currently: https://api.gentoo.org/overlays/repositories.xml) instead of using the modified one which is set by default. I've split the explanation of my concerns to a separate topic.
   Additional pitfall: If you change the URL after having used eselect repository recently, the repository list will not update. Verify if what you configure is what you get via eselect repository list and compare with the expected list from the URL. If it is wrong, you will need to delete the cache manually.
3. Check what repos you actually still need (if you're a long-time Gentoo user this is a good time to get rid of no longer required overlays): qlist -I -R | grep -v ::gentoo
4. List all overlays you previously synced with: layman -l
5. Check if that repository is available from the list you selected: eselect repository list | grep reponame
6. Delete from Layman: layman -d reponame
7. Re-add:
   • If it is listed: eselect repository enable reponame
   • If it is not and you still need it, use the URL from Layman: eselect repository add reponame git https://...
8. Check if the repository has a reasonable URL (i.e. not the "mirrors" on GitHub): cat /etc/portage/repos.conf/eselect-repo.conf
   If you find anything unexpected, eselect repository disable reponame and reconfigure manually.
9. Repeat from 5. for all remaining overlays
10. Check that you didn't forget anything: ls -al /var/lib/layman
11. Sync everything in one go: emerge --sync
12. Remove Layman; for me that was:

    Code: Select all

    equery depends layman # optional check, just in case something actually depends on layman
    emerge -Cav layman
    rm -Rf /var/lib/layman
    rm /etc/portage/repos.conf/layman.conf
    rm -Rf /etc/layman

[tld]

I was using layman just for the palemoon browser. In my case this was all pretty straight forward:

Code: Select all

emerge -av app-eselect/eselect-repository

After that I listed my existing layman repo so I knew what to add, deleted it from layman, and added it with eselect:

Code: Select all

layman -l
layman -d palemoon
eselect repository add palemoon git https://github.com/deu/palemoon-overlay.git

Then I synced it with:

Code: Select all

emaint sync -r palemoon

The uninstalled layman:

Code: Select all

emerge -aC layman

Tom

[Ralphred]

...useful stuff...

Thanks bro, really wasn't in the mood to go reading man pages.

[grknight]

Just please do not use the -C option to emerge. Always use -c except in extreme circumstances such as temporarily removing a "hard blocking" issue where something will be reinstalled immediately after.

[tld]

Just please do not use the -C option to emerge. Always use -c except in extreme circumstances such as temporarily removing a "hard blocking" issue where something will be reinstalled immediately after.

Interesting. Thanks for that. In cases where I've tended to use -C in the past it's generally when I knew there wasn't any issue, like removing a previous kernel etc. I'd actually never noticed that -c was the same as --depclean. I've generally only used --depclean for post-update dependency cleaning (without any specific package name). So am I correct that this:

Code: Select all

emerge -ac layman

...would never unmerge anything other than the specified package, and would simply refuse to unmerge it if anything depended on it? Thanks again!

EDIT: Never mind...Looking at "man emerge" I see that that is in fact what it does.

[Strunzdesign]

Wow, as a long term Gentoo user your remark regarding "emerge -C" vs "emerge -c" was pure gold! I was not aware of this. I need to spread this among my colleagues.

Besides this, I have some questions regarding the topic of this thread:

On all my machines I maintain a file "gentoo.conf" in my /etc/portage/repos.conf/ folder. After migration, if I delete this file as a test, and portage continues to work normally (using eix-sync). Thus, is this file still required, or is it advised that users remove it?

Second, there is a "gentoo" repository that can be enabled with "eselect repository enable gentoo". If I enable this, I get an error message that the destination directory is not empty.
Now I question myself whether this "option" of adding a "gentoo" repository should not be there (as everybody unpacks a portage tree sometimes during the first setup), or whether this is intended to be the modern way to use Gentoo, requiring another step of manual migration.

Third, at work, "eselect repository" refuses to work on my main box due to our proxy performing SSL interception. I needed to edit "/usr/share/eselect/modules/repository.eselect" in order to add "--no-check-certificate" to the wget command. Maybe someone has the same issue and considers this helpful.

Regards,
Florian

[grknight]

Third, at work, "eselect repository" refuses to work on my main box due to our proxy performing SSL interception. I needed to edit "/usr/share/eselect/modules/repository.eselect" in order to add "--no-check-certificate" to the wget command. Maybe someone has the same issue and considers this helpful.

Don't edit the module as it will be overwritten later on update.

If you need global settings for wget, place them in /etc/wgetrc instead. Optionally place in portage (or whatever sync-user is set to in the repos.conf entry) user's ~/.wgetrc instead.

Setting should be check_certificate=off in wgetrc in this case.

[Strunzdesign]

Thanks a lot grknight, this is the comment I was looking for, I really appreciate that!

I was not aware that "wget" invoked by portage uses this global config file, I joked today that I need to find the home directory of portage in order to place a .wgetrc there

Regards,
Florian

[logrusx]

Besides this, I have some questions regarding the topic of this thread:

On all my machines I maintain a file "gentoo.conf" in my /etc/portage/repos.conf/ folder. After migration, if I delete this file as a test, and portage continues to work normally (using eix-sync). Thus, is this file still required, or is it advised that users remove it?

/etc/portage/repos.conf Wiki page:

If /etc/portage/repos.conf/gentoo.conf does not exist, defaults from /usr/share/portage/config/repos.conf will be used, (unless /etc/portage/repos.conf is a file with a valid "[gentoo]" section, as used to be the default). If some necessary settings, such as sync-uri are omitted from /etc/portage/repos.conf/gentoo.conf, values from /usr/share/portage/config/repos.conf will be used. Some values, such as priority, will be automatically added by Portage even if they are not present in any configuration file.

Best Regards,
Georgi

[Zarhan]

Finally got around to doing this.

Anyway, there actually was a way to migrate...essentially, just rename /etc/portage/repos/layman.conf to eselect-repo.conf and rename key "layman-type" to "sync-type", like below and add the URL into the configuration as sync-uri (layman didn't store this). Example is throttled repo for my Thinkpad:

Layman:

Code: Select all

[throttled]
priority = 50
location = /var/lib/layman/throttled
layman-type = git
auto-sync = No

eselect-repository:

Code: Select all

[throttled]
location = /var/db/repos/throttled
sync-type = git
sync-uri = https://github.com/erpalma/throttled-overlay.git
auto-sync = No

[logrusx]

Finally got around to doing this.

Anyway, there actually was a way to migrate...essentially, just rename /etc/portage/repos/layman.conf to eselect-repo.conf and rename key "layman-type" to "sync-type", like below and add the URL into the configuration as sync-uri (layman didn't store this). Example is throttled repo for my Thinkpad:

Layman:

Code: Select all

[throttled]
priority = 50
location = /var/lib/layman/throttled
layman-type = git
auto-sync = No

eselect-repository:

Code: Select all

[throttled]
location = /var/db/repos/throttled
sync-type = git
sync-uri = https://github.com/erpalma/throttled-overlay.git
auto-sync = No

I won't comment on this being the correct way to do it, because I don't remember my findings when I emerged layman just to investigate your case and I don't have the time to do it again. My feeling is it's not.

What I'll comment on for the innocent user who would land on this thread is this is more work than just removing them from layman and adding them from eselect-repository and deleting /var/lib/layman for good. I can't imagine who would consciously opt out for that knowing the amount of work in advance.

Best Regards,
Georgi

[ExecutorElassus]

So, somewhat related problem: after following c00l.wave's instructions, I now am getting errors that /var has no space left on the device, which is due to running out of inodes. I've deleted the layman repos, but is there any other way to free up space on /var? The partition itself is already at 90% usage; would I have to use vgexpand to try to add more space? (note: /var/portage/repos and /var/portage/distfiles are their own partitions, so the only thing on /var itself that's taking up much inode space is /var/db)

cheers,

EE

[asturm]

You should start your own thread.

[ExecutorElassus]

done.