On Wed, 13 Aug 2008 23:33:04 +0300
Petteri Räty <[EMAIL PROTECTED]> wrote:
As a distribution we should strive to make as many packages available
with as many features as possible on as many architectures (or indeed
operating systems) as possible.[1] Not communicating important changes
in ebuilds to arch teams, even making decisions on their behalf, we risk
having to mend increasingly complex systems of profiles and flags.
> I have been instructing people to adjust the files themselves. The
> changes affect only the package in question and as such it falls
> under the responsibility of the maintainer of the package.
Sadly, I've been adding capitalised boilerplate pleas to the heads
(and sometimes the tails) of hppa profile files requesting bug reports
instead of adding silently to the ancient cruft that's there already.
That doesn't mean that either you or I are wrong, but it does clearly
show that we should put this all down in writing[2] when we find
agreement. :)
> > I personally think no, individual ebuild devs shouldn't touch
> > arch-profiles. They should simply drop the (broken) keywords and
> > file a keywordreq bug for those arches. Then the arch-teams can
> > test and eventually decide whether to keyword the package or mask
> > the use-flag.
There should be no problem committing the ebuild with dropped keywords,
then filing a KEYWORDREQ bug report describing the problem and the
solution, and CC'ing the stricken arch teams.
> The arch teams don't have that much staff so not adding to their work
> load is the best way to go imho.
Cleaning up *use.mask is annoying work and removing a flag from
*use.mask could affect many users (emerge --newuse world). We should
therefore reluctantly mask USE flags and let profile maintainers decide
what is useable and practical to have on their OS/arch. When in doubt
whether to mask a USE flag or drop a keyword, a package maintainer
should commit the ebuild, drop the keyword and file a bug to have the
arch team decide. Important note: leaving the keyword dropped is no
option for active, security supported arches[3].
Kind regards,
JeR
[1] That's my interpretation of much of what
http://www.gentoo.org/main/en/philosophy.xml says.
[2] The end result should probably trickle down into the devmanual
(and/or the Developer Handbook?) at some point. I feel like writing
a section or two about arch workflows and keywording processes that
could be included in
http://devmanual.gentoo.org/keywording/index.html .
[3] When an arch team cannot handle the workload any longer, the support
level should be dropped to ~arch anyway. I would really hate to
see people do what amounts to crippling packages (removing
features), just to decrease some arch team's workload. In the mean
time, do pile up the work regardless of staffing problems - somebody
new may just volunteer to help an arch team out when the going gets
tough.
