Re: [gentoo-dev] Making systemd more accessible to "normal" users

2013-05-10 Thread Ralph Sennhauser
On Wed, 8 May 2013 13:37:51 -0400
Rich Freeman  wrote:

> Bottom line is that none of this should really be inconveniencing
> maintainers much - nobody is required to create unit files.  However,
> if a friendly user submits a bug with one attached, then the
> maintainer should strongly consider adding them to the package at the
> next convenient time.

Indeed no maintainer should be bothered with having his package install
a unit file, though two points.

A maintainer usually dislikes adding something contributed by a user
that he doesn't know about / can't verify . So letting systemd herd
picking unit files and committing them I think is reasonable. The
chance for screwing with a package by just adding the unit file are
close to zero even if not familiar with the package.

The other thing is those unit files really should come from upstream
and other distributions urge their developers to work with upstream [1]
Therefore I'd require an upstream bug for each unit that we add.


[1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files



Re: [gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)

2013-05-10 Thread Ralph Sennhauser
On Wed, 1 May 2013 19:18:52 -0600
Ryan Hill  wrote:

> On Wed, 1 May 2013 10:14:02 +0200
> Ralph Sennhauser  wrote:
> 
> > On Tue, 30 Apr 2013 21:25:40 -0600
> > Ryan Hill  wrote:
> > 
> > > I'm also going to rename the "test" flag to "regression-test" or
> > > something similar to get it out of FEATURES="test" control.  The
> > > testsuite is a huge time-suck and only useful to developers IMO
> > > (always expected to fail and primarily meant to be used to check
> > > for regressions between patchsets).  I'm a big supporter of
> > > FEATURES="test" by default and I think this is a small step
> > > towards that.
> > 
> > This step is so tiny that we wont ever reach the goal like this.
> 
> I was hoping it would set a precedent and then people would start
> thinking of splitting up test into categories, maybe even start a
> thread about it ;).

Hehe, yes, you forced me to speak up with trying to set a precedent I
think will get in the way of solving it in a more complete way.

Though for that we have to agree on

 - split is desirable
 - which categories and how to classify tests
 - how to implement the splitting (EAPI support?)

[...]

> > ... and improve on how to configure Portage whether to run tests of
> > any given category.
> 
> Yeah I'd love to be able to do something like emerge TESTS="dev qa
> system -extradeps -expensive" @world.
> 
> 

I was thinking about a /etc/portage/package.test that works more like
package.use. So most users will want to have something like:

  # package.test
  */* cheap

Others might use:

  # package.test
  */* cheap normal
  */*::sunrise expensive

  my-pkg/foo *

  # broken test suite, bug XXX
  =dev-foo/bar-1.1 -*

This would also be pretty similar to what your regression-tests useflag
for gcc would have been. Even though Portage allows you to configure
FEATURES=test on a per package basis since a couple years it doesn't
seem to have become a common practice. While Portages mechanism is
powerful it might be just to complex or tedious for the average user.


As for your example command line 'emerge TESTS="dev qa system
-extradeps -expensive" @world', could you elaborate on what the
categories dev qa system are about?


signature.asc
Description: PGP signature


Re: [gentoo-dev] Making systemd more accessible to "normal" users

2013-05-10 Thread Rich Freeman
On Fri, May 10, 2013 at 3:45 AM, Ralph Sennhauser  wrote:
> The other thing is those unit files really should come from upstream
> and other distributions urge their developers to work with upstream [1]
> Therefore I'd require an upstream bug for each unit that we add.

Makes sense, though I wouldn't necessarily make it a hard requirement.
 Also, upstream units may not be usable as-is.  They might reference
incorrect file locations (though I'd hope not for the most part), and
in particular dependency naming will always be a challenge.

Upstream rejection of a unit should certainly not lead to Gentoo
rejection of a unit, any more than their rejection of a script for
OpenRC should.  Upstreams will likely be slow to embrace the
init-scripts-aren't-just-for-distros thing.

Rich