On Tue, 13 Sep 2016 19:49:22 -0400 Michael Orlitzky <[email protected]> wrote:
> > Patches:
> > * Wildcard patching: Usually i use my "patchtest" script for finding
> > obsolete patches and while it still finds lots of false
> > positives i also saw a rather odd patching style: Patching via
> > wildcards. For example:
> > epatch "${FILESDIR}"/${P}*.patch
> > I looks a bit unsafe to use wildcards for patching, but I
> > couldn't find anything which forbids it. Would be nice to know
> > if that is ok.
>
> Please file a bug and tell people not to do that. If they ever need to
> add a new patch, it would affect old stable ebuilds and violate our
> policy on the matter.
>
> It would be nice if we could add this check to repoman; however, some
> wildcard constructs are safe. For example, if we're pulling in a bunch
> of Debian patches in SRC_URI, it makes sense to apply them all. The
> SRC_URI is guaranteed not to change out from under us, unlike the
> contents of FILESDIR.
Clearly the problem is not the use of wildcards in "epatch", but the use of
wildcards
anywhere in conjunction with "${FILESDIR}"
For instance, if they were not patches, but blobs of shell script ala eblits,
you might
see the following happen:
for i in "${FILESDIR}"/${P}*.sh"; do
source $i
done
This would also be a QA Violation because it would be just as likely to be
broken by bumps
as patches.
>
> > * scripts in FILESDIR: In some packages i found scripts which doesn't
> > get used by the ebuild, but is probably used for generating
> > patches/tarballs. Should i file a bugs about them as i though the
> > FILESDIR should be only used for patches. Wouldn't be
> > /etc/portage/scripts the perfect place for such scripts?
>
>
> If they're not used by the tree, they probably don't belong in the tree,
> but maybe I lack imagination. Can you give a few examples?
I agree if that if the scripts in question aren't used by the ebuilds, then
grounds to keep them included are weakened.
However, It rather depends on what those scripts are doing and how important
it is to keep those scripts synchronised between developers working on a given
thing.
If for instance a given specific ebuild needs some scripts to generate parts of
ebuilds
in a consistent way, but the result of it is static code that is placed in the
ebuild,
then under the grounds of "ebuild doesn't use it", it would be removed.
But that script has no other place to be stored that makes sense, because
putting it
in an isolated repo just hides the existence of that script, and discourages its
use when its use should be encouraged.
And putting it somewhere other than gentoo.git means there's another step
required
by maintainers to keep the tree "updated" and coherent, and reduces another
place
failures can leak in if they forget to sync the independent repository.
Thus, it introduces a conflict of purpose:
1. We need certain things to be centralised and "in the repo" for the point of
maintainership and coherence.
2. We desire things that users don't strictly need don't get replicated where
they're not wanted.
A dogma of keeping the tree clean thus penalises how developers work, and makes
it harder to produce the quality we want to deliver to users, but having them
in tree reduces the quality we deliver to users.
Though, to be pragmatic, the burden of having those scripts present in tree
seems more a cosmetic problem from the users perspective, while removing them
produces a functional problem.
So I'd reason that as long as these scripts follow policy of not being
too large, and they're not abused everywhere, the pragmatic view is to permit
them staying.
pgpcvw3SHqhZW.pgp
Description: OpenPGP digital signature
