Bug 248603 – sys-apps/portage-2.2 warns about missing repo_name in local overlay

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Pacho Ramos 2008-11-24 11:11:08 UTC]

I have a local overlay in /usr/local/portage for my own ebuilds, after updating to portage-2.1.6_rc1 from current stable I get the following warning:
# emerge -avuDNtl world
WARNING: One or more repositories have missing repo_name entries:

	/usr/local/portage/profiles/repo_name

NOTE: Each repo_name entry should be a plain text file containing a
unique name for the repository on the first line.

I think that this should be handled in a better way as a lot of users will have a local overlay in /usr/local/portage without this file (or even without a profiles/ subdir). Maybe:
1. profiles/repo_name shouldn't be required for local overlay as most of users using it will know what this overlay is for :-)
2. profiles/repo_name could be autogenerated if it's missing with a name like "local" (for example)
3. Gentoo Handbook should be updating for asking users to create this file when creating a local overlay

I don't know what is the better option, maybe "2" will be better from my point of view as it's the more "automagical" ;-), but it's not up to me to decide that

Thanks a lot

Reproducible: Always

[Comment 1 Zac Medico 2008-11-25 09:46:30 UTC]

If a repo name is missing, maybe it should automatically substitute some sort of hash of the repo's path as the repo name. For example, it could use the path itself, or an md5 digest of the path. That way, we'd still have a unique id for to reference the repo, and there wouldn't be any need to burden the user in cases when they don't care to pick a particular name.

[Comment 2 Marius Mauch (RETIRED) 2008-11-25 13:35:46 UTC]

(In reply to comment #0)
> 1. profiles/repo_name shouldn't be required for local overlay as most of users
> using it will know what this overlay is for :-)

The primary purpose of the name is not to describe the contents of the repository, but to allow package management tools to identify the repository in a reliable way (using the path isn't reliable)

> 2. profiles/repo_name could be autogenerated if it's missing with a name like
> "local" (for example)

The package manager should IMO never write to $PORTDIR or $PORTDIR_OVERLAY unless explicitly requested by the user (e.g. when generating Manifests).

> 3. Gentoo Handbook should be updating for asking users to create this file when
> creating a local overlay

That would be a task for the docs team.

(In reply to comment #1)
> If a repo name is missing, maybe it should automatically substitute some sort
> of hash of the repo's path as the repo name.

The whole point of using a name is to avoid using the path to identify a repository, so that kinda defeats the purpose. You should know by now that using a path for identification purposes is causing problems (symlinks, moves, ...).
I guess another option might be to create a new emaint command to generate the repo_name file(s) for overlays missing them, either asking the user for a name or generating a random one (with a "local-" or "auto-" prefix to avoid collisions), if it's really too much to ask of the user to create the file manually.

[Comment 3 Zac Medico 2008-11-27 04:18:10 UTC]

I've disabled the warning in 2.1.6_rc2 since the 2.1.6 branch needs to be marked stable as soon as possible.

[Comment 4 nm (RETIRED) 2008-11-29 00:31:00 UTC]

(In reply to comment #2) 
> > 3. Gentoo Handbook should be updating for asking users to create this file when
> > creating a local overlay
> 
> That would be a task for the docs team.

Removing the GDP for now, as we don't document ~arch stuff as it's still in flux. If this still needs to be addressed in 2.2 once it's stable, we will re-evaluate then.

[Comment 5 Zac Medico 2013-08-12 21:26:12 UTC]

(In reply to Pacho Ramos from comment #0)
> 1. profiles/repo_name shouldn't be required for local overlay as most of
> users using it will know what this overlay is for :-)

This is implemented in git:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=60ce6cc9ad7b050d2cb6a66c84867bd5613a09a2

[Comment 6 Zac Medico 2013-08-13 00:03:10 UTC]

This is fixed in 2.2.0.