Am Dienstag 01 Mai 2012, 11:16:25 schrieb Ciaran McCreesh:
> On Tue, 1 May 2012 11:01:57 +0200
> 
> "Andreas K. Huettel" <dilfridge@g.o> wrote:
> > Am Dienstag 01 Mai 2012, 10:38:41 schrieb Ciaran McCreesh:
> > > > Well. PMS describes the files in a profile directory. If
> > > > * we introduce a new file via PMS that was not in there before,
> > > > * and another package manager accesses that file but expects
> > > > different information there not corresponding to our new
> > > > definition, that package manager should be considered broken
> > > > because it is not adhering to previous PMS revisions. So?
> > > 
> > > What happens if a user uses an EAPI 4 ebuild with an EAPI 4 package
> > > manager when the ebuild in question would be hit by your new files,
> > > which the package manager doesn't know about yet?
> > 
> > Err, nothing? The useflags remain available and switchable as before,
> > no difference regarding useflags between stable / not stable?
> 
> What is the impact of this, then? Does it mean users will start to see
> lots of "masked" errors that they should not be seeing?

If

* the ebuild is <= EAPI 4
* the ebuild is listed in package.stable.use.(mask|force)

then it will be possible to enable/disable features in the stable variant that 
are not really deemed suitable for a "stable package" yet. All quality 
requirements from ~arch remain, meaning also the use flag combinations should 
lead to a successful build and a reasonably working package. Also, the stable 
ebuild will then eventually depend on non-stable packages, which is bad.

Thus, I would strongly recommend that this situation is treated as a blocker 
for stabilization (either upgrade EAPI or modify the package.stable.use.(mask|
force) entry so it does not apply to this ebuild).
Repoman could prevent such a commit.

It might make sense to go even further and write explicitly that 
package.stable.use.(mask|force) entries must not resolve to any <= EAPI 4 
ebuilds. Unfortunately there is no automatic repoman check during commits in 
the profile dirs which could prevent it.


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@g.o
http://www.akhuettel.de/