Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] about non-ebuild files in the tree (and verification thereof)
Date: Thu, 01 Mar 2018 08:15:33
Message-Id: 1519892120.887.4.camel@gentoo.org
In Reply to: [gentoo-dev] about non-ebuild files in the tree (and verification thereof) by Fabian Groffen
1 W dniu śro, 28.02.2018 o godzinie 16∶10 +0100, użytkownik Fabian Groffen
2 napisał:
3 > Hi,
4 >
5 > I'm working on a verification implementation of
6 > https://www.gentoo.org/glep/glep-0074.html and ran into the following
7 > scenario that I don't know if it's right or wrong:
8 >
9 > Consider net-misc/srf-ip-conn-srv
10 > % ls
11 > files Manifest metadata.xml srf-ip-conn-srv-9999.ebuild
12 > srf-ip-conn-srv.pid
13 > % cat Manifest
14 > DIST jsmn-35086597a72d.tar.gz 11056 <snip>
15 > DIST srf-ip-conn-140c9b8a8619.tar.gz 112882 <snip>
16 >
17 > Notice that there is a .pid file in the ebuild dir, checked in git,
18 > which even contains what appears to be a pid. It isn't used from the
19 > ebuild as far as I can tell. Apart from being odd, this is actually
20 > irrelevant.
21 >
22 > In an rsync checkout of the gentoo-x86 tree, I see in the Manifest for
23 > this package a DATA entry for the .pid-file. Hence, verification with
24 > both gemato as well as my own implementation succeed because the
25 > .pid-file is acknowledged.
26 >
27 > Now in a rsync checkout of the Prefix tree, where my own implementation
28 > also runs the fat manifest creation, this entry is not present, because
29 > I always believed only metadata.xml, ChangeLog* and *.ebuild files were
30 > allowed.
31 >
32 > Now I'm confused as to whether this is the case or not, I can't find a
33 > GLEP or anything, but repoman also is as happy as it can be on this odd
34 > file (I thought it used to complain about stray/unadded files).
35 >
36 > Does anybody know or have a pointer to what the policies on files in our
37 > ebuild dirs actually is?
38 >
39
40 I'm going to have the usual answer here: it was not rejected because
41 nobody predicted such a thing could happen. Since ebuilds do not have
42 a clear way of accessing this file, there is no clear reason why anyone
43 would try to add such a file.
44
45 Plus, given it's a special location (again, not accessible directly to
46 ebuilds) there's the argument of forward compatibility others mentioned.
47
48 --
49 Best regards,
50 Michał Górny