Hi all (well, ok, Hi Kito, Lina and Hasan basically ;))
I'd like to start a little discussion on keywording packages ppc-macos
(stable).
As you might recall, I've expressed my concerns about broken stable and
unstable packages in the tree before, and had some crazy ideas about
implementing a testing system on it. Not much advance in that area,
mainly due to time limitations, as well as other projects that keep me
busy (just to give you a little update):
- MonetDB/Armada simulator
- MonetDB/5
- Going through historic bug reports on bugzilla for ppc-macos
- Emailing you guys in order to try and keep things running
Last weekend, when I was in bug-fixing batch-mode, I got into a
discussion with Kito, when he encountered another broken package marked
as stable. It had no Changelog entry for the stable keyword, but
luckily CVS doesn't lie. It brought on the topic of keywording packages
stable for ppc-macos. To fuzzy quote Kito:
"If an unstable package is broken, that is a serious problem, but ok,
it's unstable for a reason. However, if a *stable* package is broken..."
I couldn't agree more with this, as stable packages just should work.
But I don't think there will be people here that disagree. However, I
also agree with Kito that we *should not* mark packages stable when we
don't have to. I will elaborate on this stand point from my side here.
More and more I start to realise and experience the fact that Portage on
OSX as it is now, is nothing more than a dirty hack, which results in
much more dirty, tricky, hairy and ugly hacks. We lie, cheat and steal
to get Portage doing what we want it to do, and keep on relying on pure
coincidence and luck that everything works as portage expects. Hence,
saying a package is *stable* is almost a contradiction in itself, as the
whole engine behind it (portage) cannot be considered to be solid and
stable fitted on OSX.
I propose to keep the following keywording rules for whatever we do from
now:
1) only keyword new packages ~ppc-macos; don't stable them after a month
2) only stable new ebuilds if this is required by security stuff and we
have an older ebuild that is stable
Given the two rules above, there are some extra details:
- not stabling packages means no worries on keeping track of them
- with the userbase we have (feedback), it feels unreasonable to mark
anything stable after a month hearing nothing on it, you don't even know
if someone tried it!
- by keeping stuff unstable we underline the experimental nature of
Portage on OSX and perhaps slow down broad use of Portage
- slowing doen further use is good at the moment, because when a new
Portage will give us the proper handles, every current user has to
switch somehow, and for us big things will change, so better have people
starting from scratch then
- we are simply in many cases not able to offer an alternative to fink
and DP quality wise, we're working hard, but lack the proper setup
(think of missing/lacking perl, gtk+, etc)
- we reduce running the risk of having a broken stable package in portage
- and finally, we will be better prepared to let portage 'force' doing
many updates once we stable them if we have a better Portage infrastructure.
So, what do you guys think?
--
Fabian Groffen
eBuild && Porting
Gentoo for Mac OS X
--
[email protected] mailing list
