'ebuild some.ebuild manifest' generate Manifest without files with "@" in name examples: ================ portage-2.1.10.49: cat stuff/sys-apps/systemd-units/Manifest | awk '{print $2}' | grep \@ services-desktop/gdm@.service services-desktop/kdm@.service services-desktop/openvpn@.service services-desktop/slim@.service services-server/vsftpd@.service sshd@.service ================ >portage-2.1.10.49: cat stuff/sys-apps/systemd-units/Manifest | awk '{print $2}' | grep \@ sshd@.service ================ example tree attached ~x86 //sorry my bad english Reproducible: Always
Created attachment 308069 [details] example tree
*** Bug 411123 has been marked as a duplicate of this bug. ***
*** Bug 411125 has been marked as a duplicate of this bug. ***
*** Bug 411119 has been marked as a duplicate of this bug. ***
The change is due to bug #406877, since repoman only allows [a-zA-Z0-9._\-+:] in file names. I'd suggest to replace the '@' character with a special string, and then make the ebuild use sed to replace the special string when it installs the files.
(In reply to comment #5) > The change is due to bug #406877, since repoman only allows > [a-zA-Z0-9._\-+:] in file names. I'd suggest to replace the '@' character > with a special string, and then make the ebuild use sed to replace the > special string when it installs the files. rename...is it a joke?
No joke. Any repository where ebuilds are committed with repoman has never allowed file names containing characters other than [a-zA-Z0-9._\-+:]. I suppose that we could add some setting for metadata/layout.conf which would loosen this restriction.
(In reply to comment #7) > No joke. Any repository where ebuilds are committed with repoman has never > allowed file names containing characters other than [a-zA-Z0-9._\-+:]. hm... distfiles/foo@bar - ok ${FILESDIR}/foo@bar - false bad way, isn't? > I suppose that we could add some setting for metadata/layout.conf which would > loosen this restriction. better then nothing
As a workaround for existing portage versions, you can put "thin-manifests = true" in metadata/layout.conf. This causes the Manifest to contain only DIST entries, so the names of other files are irrelevant.
*** Bug 548246 has been marked as a duplicate of this bug. ***
@qa: Is repoman's long-standing policy of only allowing the characters [a-zA-Z0-9._\-+:] in its file.name check mentioned anywhere in our policy documentation?
The only related docs that I found are these: https://devmanual.gentoo.org/ebuild-writing/file-format/ https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-160003 ("Names and Versions" section) However, they only talk about package and category names. There's no mention of names for files in ${FILESDIR}.
(In reply to Zac Medico from comment #12) > https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-160003 ("Names and > Versions" section) This is the POSIX portable character set (see http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_278) with addition of the plus sign, and I'd strongly suggest that we stick to it, for all files in the tree. (In reply to Zac Medico from comment #11) > [a-zA-Z0-9._\-+:] Why is the colon allowed there? It's a bad idea to use it for file names because of its frequent use as a separator (e.g. in PATH).
(In reply to Ulrich Müller from comment #13) > (In reply to Zac Medico from comment #11) > > [a-zA-Z0-9._\-+:] > > Why is the colon allowed there? It's a bad idea to use it for file names > because of its frequent use as a separator (e.g. in PATH). It's been allowed ever since the initial GLEP 31 commit from 2005-09-24: https://gitweb.gentoo.org/proj/portage.git/commit/?id=415435eafe50a9063f712d8b81a3b803644beda5
There are currently no files with a colon in their name in any package directory. (There are some in eclass/tests/ which isn't repoman's domain though.) So I wonder if this shouldn't be made consistent with the rules for ebuild files. @QA: Any opinion?
(In reply to Ulrich Müller from comment #15) > There are currently no files with a colon in their name in any package > directory. (There are some in eclass/tests/ which isn't repoman's domain > though.) So I wonder if this shouldn't be made consistent with the rules for > ebuild files. Sounds good to me.
Yes, the more consistent rules, the better.
I also support it.
Discussion in comments #13 - #18 is only about a potential new policy for gentoo-x86, right? Anyway I suggest that layout.conf support a new attribute whose value would be regular expression specifying allowed filenames in manifests. Then a more limited value of this attribute would be set in layout.conf of gentoo-x86. Default value of this attribute in Portage should still allow colons for compatibility with other repositories.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #19) > Discussion in comments #13 - #18 is only about a potential new policy for > gentoo-x86, right? No, it is about removing ":" from the default.
(In reply to Ulrich Müller from comment #20) > (In reply to Arfrever Frehtes Taifersar Arahesis from comment #19) > > Discussion in comments #13 - #18 is only about a potential new policy for > > gentoo-x86, right? > > No, it is about removing ":" from the default. To elaborate on this a little more, I have scanned _all_ packages in _all_ git overlays listed in repositories.xml, and I found only two instances of filenames containing a colon: - git://github.com/ramereth/ramereth-overlay.git contains dev-db/postgresql-ip4r/: which clearly is unintentional. - https://github.com/mahatma-kaganovich/raw.git contains sys-kernel/genpnprd/files/_:+alsa.-use and a couple of other such files in the same directory. >> Anyway I suggest that layout.conf support a new attribute whose value would >> be regular expression specifying allowed filenames in manifests. >> Then a more limited value of this attribute would be set in layout.conf of >> gentoo-x86. >> Default value of this attribute in Portage should still allow colons for >> compatibility with other repositories. IMHO, it's not worthwhile to go through such complications, given the practically non-existent usage of colons that we see above.
(In reply to Zac Medico from comment #11) > @qa: Is repoman's long-standing policy of only allowing the characters > [a-zA-Z0-9._\-+:] in its file.name check mentioned anywhere in our policy > documentation? This is in the devmanual now: Things that do not belong in the tree: [...] • Files whose name contains characters outside [A-Za-z0-9._+-] <https://devmanual.gentoo.org/general-concepts/tree/index.html#what-belongs-in-the-tree?>
(In reply to Ulrich Müller from comment #22) > <https://devmanual.gentoo.org/general-concepts/tree/index.html#what-belongs-in-the-tree?> This should read: https://devmanual.gentoo.org/general-concepts/tree/index.html#what-belongs-in-the-tree%3F
FWICS, the policies agree that this is a no-go, and repoman certainly should not be changed to allow this in checks. As for Manifests, I would dare say thin Manifests generated via repoman are a thing of the past, and no modern repository should be using them. If repoman still doesn't cover those files, feel free to submit a patch that updates Manifest generation.
We tried to implement this change but we weren't aware of the history here: commit 2c562d782c2c518d657b1702c47b53f13329f83f (HEAD -> master, tag: githooks-20240602T201613Z, origin/master, origin/HEAD) Author: Ulrich Müller <ulm@gentoo.org> Date: Sun Jun 2 19:42:15 2024 +0200 Revert "local/update-03-filename: Allow @ in filenames" As it turns out, Portage will silently drop files containing an @ char during Manifest generation. See bug 411127 and bug 106544 for further reference. This reverts commit e24eacaa31707ef669cd5a9747a1bf08a5759fdf. Signed-off-by: Ulrich Müller <ulm@gentoo.org> Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> commit e24eacaa31707ef669cd5a9747a1bf08a5759fdf (tag: githooks-20240602T055652Z) Author: Ulrich Müller <ulm@gentoo.org> Date: Sun Jun 2 07:53:37 2024 +0200 local/update-03-filename: Allow @ in filenames As discussed in #gentoo-dev. Signed-off-by: Ulrich Müller <ulm@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> and commit 4d099f483b70fcca7407d61462b5e8d70f26c834 (HEAD -> master, origin/master, origin/HEAD) Author: Ulrich Müller <ulm@gentoo.org> Date: Sun Jun 2 19:34:42 2024 +0200 Revert "general-concepts/tree: Allow @ in filenames" As it turns out, Portage will silently drop files containing an @ char during Manifest generation. See bug 411127 and bug 106544 for further reference. This reverts commit 38de9c654dd036b304b158a32b14dbe785327938. Signed-off-by: Ulrich Müller <ulm@gentoo.org> commit 38de9c654dd036b304b158a32b14dbe785327938 Author: Ulrich Müller <ulm@gentoo.org> Date: Sun Jun 2 08:16:25 2024 +0200 general-concepts/tree: Allow @ in filenames As discussed in #gentoo-dev. Signed-off-by: Ulrich Müller <ulm@gentoo.org>
