# find "$(portageq portdir)" -mindepth 2 -maxdepth 2 -name "*[A-Z]*" -a \! -path "$(portageq portdir)/licenses*" -a \! -path "$(portageq portdir)/profiles*" -a \! -path "$(portageq portdir)/eclass*" -a \! -path "$(portageq portdir)/scripts" | wc -l 1560
uppercase has always been fine for Perl, but otherwise has been not recommended, but tolerated, at maintainer's discression what's changed?
QA hassled me last time when I wanted to use uppercase letter for an ebuild, so I thought I will open this bug so they can work on it.
As per devmanual: >The name section should contain only lowercase non-accented letters, the digits 0-9, hyphens, underscores and plus characters. Uppercase characters are strongly discouraged, but technically valid. So, if you have no really valueable reason(like overcomplicating ebuild's internals if using name without upperscore) to introduce such ebuild - please do not do it. Otherwise - go for it. That's my opinion, let's see what other QA members will say. Cause, IMO, it's WONTFIX
(In reply to Sergey Popov from comment #3) > As per devmanual: > > >The name section should contain only lowercase non-accented letters, the digits 0-9, hyphens, underscores and plus characters. Uppercase characters are strongly discouraged, but technically valid. > > So, if you have no really valueable reason(like overcomplicating ebuild's > internals if using name without upperscore) to introduce such ebuild - > please do not do it. Otherwise - go for it. That's my opinion, let's see > what other QA members will say. > > Cause, IMO, it's WONTFIX I'd rather vote for removing that wording entirely. Discouraging something has almost no effect, especially when there seems to be no good reason why it's discouraged. If there is good reason, then it should at least be a repoman warning. Neither of that currently applies.
(In reply to Sergey Popov from comment #3) > So, if you have no really valueable reason(like overcomplicating ebuild's > internals if using name without upperscore) to introduce such ebuild - > please do not do it. I mostly agree, except that a valid reason can only be too complicated _eclass_ internals. That is, if you have an eclass handling a large number of packages and case conversion would spoil matching of upstream package names. Examples are perl and modular X. Case conversion in for a single package is always trivial: If all else fails, the ebuild can assign MY_PN. So uppercase PN should really be avoided there. In spite of this, I guess we won't go for any big renaming. Package moves for established packages are a nuisance. (In reply to Julian Ospald (hasufell) from comment #4) > I'd rather vote for removing that wording entirely. Discouraging something > has almost no effect, especially when there seems to be no good reason why > it's discouraged. Consistent package naming is a very good reason to keep this policy. Maybe we should even add another sentence from the old devrel handbook: "We have some packages in Portage that don't follow these rules, but *your* packages should."
(In reply to Ulrich Müller from comment #5) > (In reply to Sergey Popov from comment #3167) > > So, if you have no really valueable reason(like overcomplicating ebuild's > > internals if using name without upperscore) to introduce such ebuild - > > please do not do it. > > I mostly agree, except that a valid reason can only be too complicated > _eclass_ internals. That is, if you have an eclass handling a large number > of packages and case conversion would spoil matching of upstream package > names. Examples are perl and modular X. > > Case conversion in for a single package is always trivial: If all else > fails, the ebuild can assign MY_PN. So uppercase PN should really be avoided > there. > > In spite of this, I guess we won't go for any big renaming. Package moves > for established packages are a nuisance. > > > (In reply to Julian Ospald (hasufell) from comment #4168) > > I'd rather vote for removing that wording entirely. Discouraging something > > has almost no effect, especially when there seems to be no good reason why > > it's discouraged. > > Consistent package naming is a very good reason to keep this policy. Maybe > we should even add another sentence from the old devrel handbook: "We have > some packages in Portage that don't follow these rules, but *your* packages > should." What about a repoman warning then? That would unnecessary avoid package moves. It could be filtered for perl packages ofc.
*avoid unnecessary
A repoman check won't help so much here, because "cvs add" will already add the package directory to the central repo. So the check would have to be added to the CVS pre-commit hook instead.
(In reply to Ulrich Müller from comment #8) > A repoman check won't help so much here, because "cvs add" will already add > the package directory to the central repo. So the check would have to be > added to the CVS pre-commit hook instead. We don't need pkgmoves for directories. So yes, it helps.
Hmm; on the one hand it helps avoid new packages of such type, on the other hand it is quite nagging for those whom already maintain a package with uppercase letters. Do we really want to do this? Do we want to expect them to change to lowercase letters too? $ find /usr/portage/ -mindepth 2 -maxdepth 2 | grep [A-Z] | grep -v '\(CVS\|licenses\|profiles\)' | wc -l 1576 $ find /usr/portage/ -mindepth 2 -maxdepth 2 | grep [A-Z] | grep -v '\(CVS\|licenses\|profiles\)' | grep -v '\(perl\|PEAR\)' | wc -l 164 With Perl and PEAR warned it are quite a lot; however, as suggested, if we exclude them then just 164 packages sounds reasonable to warn for. Do we let repoman warn for uppercase ebuilds (dev-perl/* and */*PEAR* excluded)?
(In reply to Tom Wijsman (TomWij) from comment #10) > Hmm; on the one hand it helps avoid new packages of such type, on the other > hand it is quite nagging for those whom already maintain a package with > uppercase letters. Do we really want to do this? Do we want to expect them > to change to lowercase letters too? > > $ find /usr/portage/ -mindepth 2 -maxdepth 2 | grep [A-Z] | grep -v > '\(CVS\|licenses\|profiles\)' | wc -l > 1576 > $ find /usr/portage/ -mindepth 2 -maxdepth 2 | grep [A-Z] | grep -v > '\(CVS\|licenses\|profiles\)' | grep -v '\(perl\|PEAR\)' | wc -l > 164 > > With Perl and PEAR warned it are quite a lot; however, as suggested, if we > exclude them then just 164 packages sounds reasonable to warn for. > > Do we let repoman warn for uppercase ebuilds (dev-perl/* and */*PEAR* > excluded)? Right, those are the questions that QA should decide on.
