W dniu śro, 28.02.2018 o godzinie 16∶10 +0100, użytkownik Fabian Groffen napisał: > Hi, > > I'm working on a verification implementation of > https://www.gentoo.org/glep/glep-0074.html and ran into the following > scenario that I don't know if it's right or wrong: > > Consider net-misc/srf-ip-conn-srv > % ls > files Manifest metadata.xml srf-ip-conn-srv-9999.ebuild > srf-ip-conn-srv.pid > % cat Manifest > DIST jsmn-35086597a72d.tar.gz 11056 <snip> > DIST srf-ip-conn-140c9b8a8619.tar.gz 112882 <snip> > > Notice that there is a .pid file in the ebuild dir, checked in git, > which even contains what appears to be a pid. It isn't used from the > ebuild as far as I can tell. Apart from being odd, this is actually > irrelevant. > > In an rsync checkout of the gentoo-x86 tree, I see in the Manifest for > this package a DATA entry for the .pid-file. Hence, verification with > both gemato as well as my own implementation succeed because the > .pid-file is acknowledged. > > Now in a rsync checkout of the Prefix tree, where my own implementation > also runs the fat manifest creation, this entry is not present, because > I always believed only metadata.xml, ChangeLog* and *.ebuild files were > allowed. > > Now I'm confused as to whether this is the case or not, I can't find a > GLEP or anything, but repoman also is as happy as it can be on this odd > file (I thought it used to complain about stray/unadded files). > > Does anybody know or have a pointer to what the policies on files in our > ebuild dirs actually is? >
I'm going to have the usual answer here: it was not rejected because nobody predicted such a thing could happen. Since ebuilds do not have a clear way of accessing this file, there is no clear reason why anyone would try to add such a file. Plus, given it's a special location (again, not accessible directly to ebuilds) there's the argument of forward compatibility others mentioned. -- Best regards, Michał Górny
