Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Ferris McCormick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 23 Jun 2004, foser wrote:

> > >
> > I don't think it's just duplication.  There have been so many of these, I
> > am not sure which one to attach this thought to, so I picked this one
> > because it is short.  And, if I understand your point, this speaks to it.
> >
> > I am arch(sparc), so for definiteness, I use sparc as a placeholder for
> > any architecture.
> >
> > 1.  In one instance, if I, as sparc, mark something as KEYWORDS=sparc, it
> >     means essentially one thing:  In my best judgment this package is
> >     stable for use on sparc.  It doesn't say anything about other
> >     architectures (except as evidence of goodness).
>
> You are not the package maintainer, you should not mark it stable before
> that happens. So your arch going stable has no wider significance.
>
Sure it does, unless the maintainer never makes mistakes.  It's more
evidence that the package is good (consider the endian problems which
come up now and then.  If maintainer is little-endian and sparc goes
stable, that suggests to other big-endian archs that there is probably
not an endian concern. Look at games, sys-cluster, and I think you'll
find examples where number of stable architectures matters.)
 
> > 2.  In a second instance, I am sparc & package maintainer. Now, if I
> >     mark this package stable on sparc, I might mean one or more of at
> >     least two possibilities:
> >       a.  I am package maintainer, I believe this package is stable,
> >           and I happen to be on sparc.
> >       b.  I believe this package is stable on sparc, and I happen to
> >           be its maintainer.
>
> What is the difference between a & b, they look the same to me. If you
> are the package maintainer and sparc is your arch, then that means that
> it is now safe for other arches to move to stable as well (if they do
> not have arch specific issues).
>

For 2.b: Consider a LaTeX document class (there are some in portage) --
almost certainly architecture-neutral, and maintainer's blessing is
almost certainly definitive.

For 2.a: Consider a multiprocessor performance measurement tool working
at a very low level. -- almost certainly architecture-specific, and
maintainer's blessing might mean only that it's usable on a specific
architecture.

In case 2.b, if I am interested in the package, I should follow the
maintainer.  In 2.a, what the maintainer thinks could be completely
irrelevant to my arch, ranging from {-sparc, ~sparc, sparc}, and I
just thank the maintainer for the package.  (Portage has performance
measurement tools; I really don't know if any work at this level.)
 
> A 'package maintainer' is someone who is responsible for the general
> ebuild, not it's arch specific parts. But naturally, the 'package
> maintainer' is on some arch and will take care of needs specific for
> that arch as well.
>

OK.  My example for 2.a is for packages which are almost all 
architecture-specific, so that the maintainer's view of the world has
little relevance to how other people look at it.


> - foser
>

- --
Ferris McCormick (P44646, MI) <fmccor@g.o>
Developer, Gentoo Linux (Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2dOnQa6M3+I///cRAnGVAJ4qCvGtI7vilZtsF+997dNGy6IhkQCggFDy
Bh1gT61PgppBYMW75OTM6Mo=
=5R76
-----END PGP SIGNATURE-----

--
gentoo-dev@g.o mailing list