Mailing List Archive

On Sat, 3 Sep 2005, Grobian wrote:

> From a freshly reported bug:
>
> Reproducible: Always
> Steps to Reproduce:
> 1. Install gentoo for OSX and not be perfectly comfortable you did it
> right.
> 2. Add ~ppc-macos to the keywords for the mediawiki-1.4.9.ebuild.
> 3. ACCEPT_KEYWORDS="~ppc-macos" emerge mediawiki
>
> Here is where I want the discussion to start. I myself would have done
> it exact the same way, and I see it happen a lot. In fact, I even think
> this is the way the Gentoo docs advocate the use of ~arch.
>
> What's wrong with it?
>
> In a recent discussion I found out this is, however, not the way some
> other people see the use of ~arch. Instead they assume your whole
> system is ~arch.

Like gentoo was running a "testing" branch? As in, you aren't allowed to
keyword an ebuild ~ unless it works with all the other ~ packages? Doesn't
seem realistic.

> This very bug reported might be fixed if the whole system would be
> ~ppc-macos, however, the user doesn't want that. Instead, the user
> wants to use an unstable package, to have a very isolated case, where an
> unstable package lives as a stable one. As far as I know, this is the
> whole thing on Portage. It allows you to do this, and it enables you to
> do this, and it even facilitates you to do this more automated, for
> instance via package.keywords.

I hope you are right about that...

> My opinion here is that there is something wrong if portage isn't able
> to tell what it needs to run a package in ~ppc-macos.

Yeah. FWIW, I think that if a package is marked ~keyword, that should mean
that the deps are sane. i.e. if ~ mediawiki needs ~ webapp-config, then
the deps should say so.

> Maybe this is not easily fixable, and should we do some extra hacks to
> make the two worlds play nice again. However, I don't think having a
> fully ~arch system is equal to a user that runs a stable system and
> wants to grab one package from the unstable branch. I consider the
> first case to be 'progressive' (not in the ppc-macos sense) or 'bleeding
> edge' while the latter case is more realistic and what happens in real
> life: 'controlled risk'.
>
> I like to straighten out this issue, so everyone knows what should be
> done or not be done. I just assumed the only vision I knew was what
> everyone has in mind, and this appears not to be like this. I think
> it's directly related to QA and I feel my actions largely depend on it.
> So, until I know what I'm doing is right or wrong, I won't do anything.

From what I've read on this list over the past few weeks, it seems to be a
damage control problem (not really a portage limitation) in that a whole
bunch of stuff is keyworded wrong.

-f
--
gentoo-osx@gentoo.org mailing list

Grobian wrote:
> From a freshly reported bug:
Bug # may be useful just to serve as a reference.

> Reproducible: Always
> Steps to Reproduce:
> 1. Install gentoo for OSX and not be perfectly comfortable you did it
> right.
Not comfortable with the install? Are our docs outdated or ambiguous?

> 2. Add ~ppc-macos to the keywords for the mediawiki-1.4.9.ebuild.
> 3. ACCEPT_KEYWORDS="~ppc-macos" emerge mediawiki
No problem so far.

> Here is where I want the discussion to start. I myself would have done
> it exact the same way, and I see it happen a lot. In fact, I even think
> this is the way the Gentoo docs advocate the use of ~arch.
Is the goal to test out an unkeyworded ebuild for keywording/porting?
This looks like a good way to go for that purpose.

> In a recent discussion I found out this is, however, not the way some
> other people see the use of ~arch. Instead they assume your whole
> system is ~arch.
Indeed, mine is a ~ppc-macos portage system.

> This very bug reported might be fixed if the whole system would be
> ~ppc-macos, however, the user doesn't want that. Instead, the user
> wants to use an unstable package, to have a very isolated case, where an
> unstable package lives as a stable one.
What is the bug, exactly? If they're trying to run an ~arch package on
an arch system, this is how you do it. There will likely be
dependencies to also be pulled from ~arch, but portage handles that AFAIK.

> My opinion here is that there is something wrong if portage isn't able
> to tell what it needs to run a package in ~ppc-macos. Maybe this is not
> easily fixable, and should we do some extra hacks to make the two worlds
> play nice again. However, I don't think having a fully ~arch system is
> equal to a user that runs a stable system and wants to grab one package
> from the unstable branch. I consider the first case to be 'progressive'
> (not in the ppc-macos sense) or 'bleeding edge' while the latter case is
> more realistic and what happens in real life: 'controlled risk'.
Portage should handle this. As I understand it, portage doesn't care
too much about arch/~arch. The KEYWORD just sets up some default
packages masks, if you will, from which it can draw from known packages
and their dependencies. When you get down to installing a package
(regardless of keyword), portage makes sure the system and ebuild
keywords match and then it starts building the dependency tree. The
same checks must be made for each dep. If it was called something like
# ACCEPT_KEYWORDS="~arch" emerge foo/bar then for that run or portage,
the system _is_ an ~arch system, meaning all deps will be pulled from
~arch. I'm not sure how it handles entries in the package.keywords
file. The behavior may be different; feel free to chime in, anyone who
knows.

Be careful about your terms here. We currently have a use for the term
"progressive". I believe I understand what you're saying about
controlled risk; don't know if it would confuse anyone else.

> I like to straighten out this issue, so everyone knows what should be
> done or not be done. I just assumed the only vision I knew was what
> everyone has in mind, and this appears not to be like this. I think
> it's directly related to QA and I feel my actions largely depend on it.
> So, until I know what I'm doing is right or wrong, I won't do anything.
I'm afraid I don't understand what (if anything) needs to be done. Care
to elaborate?

-Nick Dimiduk
--
gentoo-osx@gentoo.org mailing list

I'm not interested at all in this bug in specific, I'm interested in the
visions on using ~ppc-macos vs ppc-macos.

If you keyword ~ppc-macos should you be on a completely ~ppc-macos
system, or does a ppc-macos system also hold?

I agree with you that portage should deal with it, and if I understood
Finn correctly, I think he thinks like me, that most users will use a
ppc-macos system and occasionaly use a ~ppc-macos package.

My current setup is equal to this: my base install is ppc-macos and I
test ~ppc-macos packages against that. Portage pulls whatever it needs
for each package I test/keyword. I argue that I simulate a 'user'
system this way. However, if some devs think you can only keyword
~ppc-macos on a fully ~ppc-macos system, then I better stop, which I
will until this is straightened out. The reason why this is brought up
now, is because there is a package which doesn't compile on a ppc-macos
system, but does on a ~ppc-macos system, because the output of emerge
-ep system is different for {,~}ppc-macos.

I still think that this difference in emerge -ep system is the actual
problem, but I want to be very sure that my setup is accepted, which it
apparently is not at the moment. Hence, I won't move a repoman commit
muscle.


Nick Dimiduk wrote:
> I'm afraid I don't understand what (if anything) needs to be done. Care
> to elaborate?
>
> -Nick Dimiduk

--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

On Sat, 3 Sep 2005, Nick Dimiduk wrote:

> Grobian wrote:
>
> If it was called something like # ACCEPT_KEYWORDS="~arch" emerge foo/bar
> then for that run or portage, the system _is_ an ~arch system, meaning
> all deps will be pulled from ~arch.

You should qualify that: all missing deps. If the ~arch bar's deps are not
accurate, and some of those deps are already installed from arch (and not
~arch), then you might need,

# ACCEPT_KEYWORDS="~arch" emerge -Du foo/bar

See, Grobian said that an all ~ppc-macos system may not have encountered
the bug, which could only mean that mediawiki was keyworded ~ppc-macos
even though its DEPEND was not complete enough to pull in all the required
deps from ~ppc-macos.

-f
--
gentoo-osx@gentoo.org mailing list

Finn Thain wrote:
>
> On Sat, 3 Sep 2005, Nick Dimiduk wrote:
>
>> Grobian wrote:
>>
>> If it was called something like # ACCEPT_KEYWORDS="~arch" emerge foo/bar
>> then for that run or portage, the system _is_ an ~arch system, meaning
>> all deps will be pulled from ~arch.

FYI: ^^^ this is *not* my quote


> See, Grobian said that an all ~ppc-macos system may not have encountered
> the bug, which could only mean that mediawiki was keyworded ~ppc-macos
> even though its DEPEND was not complete enough to pull in all the required
> deps from ~ppc-macos.

The problem is happening for real at
http://bugs.gentoo.org/show_bug.cgi?id=87758

there baselayout is necessary. However, baselayout is only pulled in
the initial "emerge system" if you use ACCEPT_KEYWORD="~ppc-macos".
Hence, I can't compile, because QTDIR is not set for me, while someone
having a complete ~ppc-macos system can. Portage won't pull the
dependency of baselayout for a reason I think, but the particular
problem sheds this light on the whole problem of how to test what on
which system.

I still think that I either shouldn't have been able to emerge QT or
that "emerge system" should provide the same base for {,~}ppc-macos,
since portage doesn't pull these packages because they are never
depended on.

I think you cannot sell a WONTFIX/REJECTED/INVALID to a user that
emerged unstable QT and doxygen on a stable profile. But people may
disagree with me here.

--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

On Sep 3, 2005, at 04:14, Grobian wrote:

> My opinion here is that there is something wrong if portage isn't
> able to tell what it needs to run a package in ~ppc-macos. Maybe
> this is not easily fixable, and should we do some extra hacks to
> make the two worlds play nice again. However, I don't think having
> a fully ~arch system is equal to a user that runs a stable system
> and wants to grab one package from the unstable branch.

We feel that you are absolutely correct here, and that a fundamental
capability of portage is to be able to tell _exactly_ what is
necessary in order to build/install/use a package. Unfortunately,
portage makes several assumptions in this process, and not all of
these assumptions are valid for the ppc-macos/~ppc-macos mixed case.

As a solution, we feel as though it's high time that the ppc-macos
(stable) keyword is dropped entirely, in favor of ~ppc-macos
(testing), tree-wide. This would obviously solve the problem detailed
by Fabian above. There are several reasons that we feel this is a
good idea, and long overdue:

* We don't have the manpower to fix, maintain or keep up with a
stable branch.
* The project is just too young, with too many fundamental (read:
system packages) aspects changing too frequently to keep up with a
stable branch without constantly breaking the 30-days-without-bugs-
before-stable 'rule'.
* Even the 'stable' branch frequently breaks (read: compile-time or
run-time errors in various packages), currently.
* Did we mention that we don't have enough manpower to fix,
maintain or keep up with a stable branch?
* We don't have a large enough user-base to justify bumping
packages from testing to stable by just waiting for the 30-days-
without-bugs-before-stable timeout to expire (this point was
previously discussed on this mailing list).
* Oh yeah, the manpower thing.
* As it is, we currently (or at the very least have, in the past,
and will, in the future) needlessly hold up older versions of various
packages from being removed from the portage tree because there is no
later version that has been marked ppc-macos (stable).
* No, really, we just don't have the manpower to fix, maintain or
keep up with a stable branch.

In summary, we wish to extend a notion[1] that was previously
mentioned on this list, and put forth that we should immediately
replace all instances of the ppc-macos (stable) keyword in KEYWORDS
with ~ppc-macos (testing).

So what's the verdict?

- Hasan && Lina

[1] That is, to hold off bumping packages from testing to stable. See
"On keywording ppc-macos", a thread started by Fabian Groffen on this
list. http://article.gmane.org/gmane.linux.gentoo.macosx/396

--

Hasan Khalil && Lina Pezzella
eBuild and Porting Co-Leads
Gentoo for Mac OS X

I will shut up and wait. Sorry.

Hasan Khalil wrote:
>
> On Sep 3, 2005, at 04:14, Grobian wrote:
>
>> My opinion here is that there is something wrong if portage isn't able
>> to tell what it needs to run a package in ~ppc-macos. Maybe this is
>> not easily fixable, and should we do some extra hacks to make the two
>> worlds play nice again. However, I don't think having a fully ~arch
>> system is equal to a user that runs a stable system and wants to grab
>> one package from the unstable branch.
>
> We feel that you are absolutely correct here, and that a fundamental
> capability of portage is to be able to tell _exactly_ what is necessary
> in order to build/install/use a package. Unfortunately, portage makes
> several assumptions in this process, and not all of these assumptions
> are valid for the ppc-macos/~ppc-macos mixed case.
>
> As a solution, we feel as though it's high time that the ppc-macos
> (stable) keyword is dropped entirely, in favor of ~ppc-macos (testing),
> tree-wide. This would obviously solve the problem detailed by Fabian
> above. There are several reasons that we feel this is a good idea, and
> long overdue:
>
> * We don't have the manpower to fix, maintain or keep up with a stable
> branch.
> * The project is just too young, with too many fundamental (read:
> system packages) aspects changing too frequently to keep up with a
> stable branch without constantly breaking the
> 30-days-without-bugs-before-stable 'rule'.
> * Even the 'stable' branch frequently breaks (read: compile-time or
> run-time errors in various packages), currently.
> * Did we mention that we don't have enough manpower to fix, maintain or
> keep up with a stable branch?
> * We don't have a large enough user-base to justify bumping packages
> from testing to stable by just waiting for the
> 30-days-without-bugs-before-stable timeout to expire (this point was
> previously discussed on this mailing list).
> * Oh yeah, the manpower thing.
> * As it is, we currently (or at the very least have, in the past, and
> will, in the future) needlessly hold up older versions of various
> packages from being removed from the portage tree because there is no
> later version that has been marked ppc-macos (stable).
> * No, really, we just don't have the manpower to fix, maintain or keep
> up with a stable branch.
>
> In summary, we wish to extend a notion[1] that was previously mentioned
> on this list, and put forth that we should immediately replace all
> instances of the ppc-macos (stable) keyword in KEYWORDS with ~ppc-macos
> (testing).
>
> So what's the verdict?
>
> - Hasan && Lina
>
> [1] That is, to hold off bumping packages from testing to stable. See
> "On keywording ppc-macos", a thread started by Fabian Groffen on this
> list. http://article.gmane.org/gmane.linux.gentoo.macosx/396
>
> --
>
> Hasan Khalil && Lina Pezzella
> eBuild and Porting Co-Leads
> Gentoo for Mac OS X
>

--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

On Sat, 3 Sep 2005, Hasan Khalil wrote:

> * Even the 'stable' branch frequently breaks (read: compile-time or
> run-time errors in various packages), currently.

Well, marking stable as testing won't change that.

> * As it is, we currently (or at the very least have, in the past, and
> will, in the future) needlessly hold up older versions of various
> packages from being removed from the portage tree because there is no
> later version that has been marked ppc-macos (stable).

Let them drop out of the tree?

> In summary, we wish to extend a notion[1] that was previously mentioned
> on this list, and put forth that we should immediately replace all
> instances of the ppc-macos (stable) keyword in KEYWORDS with ~ppc-macos
> (testing).

How many new packages/versions would this unmask for a previously stable
user who now has to switch to testing? Anyone counted them?

A couple of observations:

This action would, of course, lose some information about any packages
that actually are stable.

You can also solve the original mediawiki bug by doing the reverse
substition, i.e. aggressively marking packages as stable. This would also
meet some of your requirements. Automated builds would help too. Something
to think about.

-f
--
gentoo-osx@gentoo.org mailing list

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

> The problem is happening for real at http://bugs.gentoo.org/
> show_bug.cgi?id=87758
>
> there baselayout is necessary. However, baselayout is only pulled
> in the initial "emerge system" if you use ACCEPT_KEYWORD="~ppc-
> macos". Hence, I can't compile, because QTDIR is not set for me,
> while someone having a complete ~ppc-macos system can. Portage
> won't pull the dependency of baselayout for a reason I think, but
> the particular problem sheds this light on the whole problem of how
> to test what on which system.

This is basically the basis of Hasan and my proposal to drop stable
support for ppc-macos. The reason "emerge system" pulls in different
packages dependent on whether you are running ~ppc-macos or ppc-macos
is that baselayout-darwin and coreutils-darwin are not yet ready for
stable. What I mean by this is that they haven't been sufficiently
tested and may still change significantly.

The crux of the issue here is that we are only really pretending to
have stable support. We all agree that there are "stable" packages
that don't work. This is not "stable", and imho we shouldn't pretend
to have stable support when we really don't. Additionally, I think QA
would improve drastically if all developers could work on the same
system setup and expect users to have the same system setup.

Once we have the manpower and a less dynamic setup (right now our
profiles change frequently, we are toying with the prefixed-install
idea, baselayout and coreutils are changing) we definitely should
support stable. Until then I think it is just a misnomer that should
be dropped.

>
> I still think that I either shouldn't have been able to emerge QT
> or that "emerge system" should provide the same base for {,~}ppc-
> macos, since portage doesn't pull these packages because they are
> never depended on.

If we only had ~ppc-macos, this would have never happened, nor would
the bug on mediawiki.

>
> I think you cannot sell a WONTFIX/REJECTED/INVALID to a user that
> emerged unstable QT and doxygen on a stable profile. But people
> may disagree with me here.

You probably could, but I agree that this is not a nice solution.

- --Lina Pezzella
Ebuild & Porting Co-Lead
Gentoo for OS X

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDGezMNJ9STR9DbYERAv1BAJ9f75oIBYLudQkhmSSu29UNbLVtXgCaA0KQ
my9SUnpWlZ8/sMrN4RbRXeU=
=Z9mC
-----END PGP SIGNATURE-----
--
gentoo-osx@gentoo.org mailing list

On Sat, 3 Sep 2005, Lina Pezzella wrote:

> >The problem is happening for real at
> >http://bugs.gentoo.org/show_bug.cgi?id=87758
> >
> >there baselayout is necessary. However, baselayout is only pulled in
> >the initial "emerge system" if you use ACCEPT_KEYWORD="~ppc-macos".
> >Hence, I can't compile, because QTDIR is not set for me, while someone
> >having a complete ~ppc-macos system can. Portage won't pull the
> >dependency of baselayout for a reason I think, but the particular
> >problem sheds this light on the whole problem of how to test what on
> >which system.
>
> This is basically the basis of Hasan and my proposal to drop stable
> support for ppc-macos. The reason "emerge system" pulls in different
> packages dependent on whether you are running ~ppc-macos or ppc-macos is
> that baselayout-darwin and coreutils-darwin are not yet ready for
> stable. What I mean by this is that they haven't been sufficiently
> tested and may still change significantly.

Are there known bugs with the ~ppc-macos baselayout?

> The crux of the issue here is that we are only really pretending to have
> stable support. We all agree that there are "stable" packages that don't
> work. This is not "stable", and imho we shouldn't pretend to have stable
> support when we really don't. Additionally, I think QA would improve
> drastically if all developers could work on the same system setup and
> expect users to have the same system setup.

Yes, and if devs used stable, that would improve QA also. If the dev that
keyworded qt was using stable, s/he would have found that the qt deps were
wrong because they don't include the baselayout requirement.

> Once we have the manpower and a less dynamic setup (right now our
> profiles change frequently, we are toying with the prefixed-install
> idea, baselayout and coreutils are changing) we definitely should
> support stable. Until then I think it is just a misnomer that should be
> dropped.

Well, moving stable packages to testing also creates a misnomer.

> >
> >I still think that I either shouldn't have been able to emerge QT or
> >that "emerge system" should provide the same base for {,~}ppc-macos,
> >since portage doesn't pull these packages because they are never
> >depended on.
>
> If we only had ~ppc-macos, this would have never happened, nor would the
> bug on mediawiki.

If you had accurate QT deps, this would never have happened either. If
everyone used testing, that dep problem would never have been found. That
isn't an improvement in QA.

Can someone explain what is to be gained from this that cannot be achieved
with automated builds (e.g. to weed out the badly broken stable packages
and check the deps of the ~ppc-macos packages); as well as a policy to
relax the "30 day" rule?

-f
--
gentoo-osx@gentoo.org mailing list

On Sep 4, 2005, at 24:00, Finn Thain wrote:

> Are there known bugs with the ~ppc-macos baselayout?

Yes and no. There are design issues still in the works with it. I
think that the general consensus is that it's definitely _not_ ready
for prime-time, yet.

> Yes, and if devs used stable, that would improve QA also. If the
> dev that
> keyworded qt was using stable, s/he would have found that the qt
> deps were
> wrong because they don't include the baselayout requirement.

Uh, no? The x11-libs/qt deps are indeed correct. Please do your
homework before posting to this list; you should read up on Gentoo
policy about DEPENDS and packages that are in 'system', such as
baselayout.

Should Gentoo policy change, I would have absolutely no problem (and
would actually encourage) adding 'virtual/baselayout' to DEPENDS
where necessary. Brian Harring has also discussed this on gentoo-dev,
in relation to 'BDEPENDS'.

> Well, moving stable packages to testing also creates a misnomer.

Again, do your homework. Stable packages are a subset of testing
packages for any given arch. By specifying '~arch' in your KEYWORDS
(in /etc/make.conf), you are actually implicitly specifying 'arch'.

> Can someone explain what is to be gained from this that cannot be
> achieved
> with automated builds (e.g. to weed out the badly broken stable
> packages
> and check the deps of the ~ppc-macos packages); as well as a policy to
> relax the "30 day" rule?

What automated builds? AFAIK, we don't have an automated build
system, and one won't exist for a Real Long Time(tm). Once it does,
I'm all for keeping a stable branch. Until then, I find that keeping
a stable branch is way more work than we can keep up with, for all
the reasons cited in my previous message(s) to this list.

I don't mean to sound rude, here; I apologize in advance if I do.
Please don't take any of this personally.

--

Hasan Khalil
eBuild and Porting Co-Lead
Gentoo for Mac OS X

You better pick me as a victim, instead of an innocent, just interested
user on the mailing list.


Hasan Khalil wrote:
>
> On Sep 4, 2005, at 24:00, Finn Thain wrote:
>
>> Are there known bugs with the ~ppc-macos baselayout?
>
> Yes and no. There are design issues still in the works with it. I think
> that the general consensus is that it's definitely _not_ ready for
> prime-time, yet.
>
>> Yes, and if devs used stable, that would improve QA also. If the dev that
>> keyworded qt was using stable, s/he would have found that the qt deps
>> were
>> wrong because they don't include the baselayout requirement.
>
> Uh, no? The x11-libs/qt deps are indeed correct. Please do your homework
> before posting to this list; you should read up on Gentoo policy about
> DEPENDS and packages that are in 'system', such as baselayout.
>
> Should Gentoo policy change, I would have absolutely no problem (and
> would actually encourage) adding 'virtual/baselayout' to DEPENDS where
> necessary. Brian Harring has also discussed this on gentoo-dev, in
> relation to 'BDEPENDS'.
>
>> Well, moving stable packages to testing also creates a misnomer.
>
> Again, do your homework. Stable packages are a subset of testing
> packages for any given arch. By specifying '~arch' in your KEYWORDS (in
> /etc/make.conf), you are actually implicitly specifying 'arch'.
>
>> Can someone explain what is to be gained from this that cannot be
>> achieved
>> with automated builds (e.g. to weed out the badly broken stable packages
>> and check the deps of the ~ppc-macos packages); as well as a policy to
>> relax the "30 day" rule?
>
> What automated builds? AFAIK, we don't have an automated build system,
> and one won't exist for a Real Long Time(tm). Once it does, I'm all for
> keeping a stable branch. Until then, I find that keeping a stable branch
> is way more work than we can keep up with, for all the reasons cited in
> my previous message(s) to this list.
>
> I don't mean to sound rude, here; I apologize in advance if I do. Please
> don't take any of this personally.

--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

On Sun, 4 Sep 2005, Hasan Khalil wrote:

>
> On Sep 4, 2005, at 24:00, Finn Thain wrote:
>
> >Are there known bugs with the ~ppc-macos baselayout?
>
> Yes and no. There are design issues still in the works with it. I think
> that the general consensus is that it's definitely _not_ ready for
> prime-time, yet.
>
> >Yes, and if devs used stable, that would improve QA also. If the dev
> >that keyworded qt was using stable, s/he would have found that the qt
> >deps were wrong because they don't include the baselayout requirement.
>
> Uh, no? The x11-libs/qt deps are indeed correct. Please do your homework
> before posting to this list; you should read up on Gentoo policy about
> DEPENDS and packages that are in 'system', such as baselayout.

If that is the case, shouldn't qt be hard masked? If you move everything
from arch to ~arch, you will be doing a lot more of that.

> Should Gentoo policy change, I would have absolutely no problem (and
> would actually encourage) adding 'virtual/baselayout' to DEPENDS where
> necessary. Brian Harring has also discussed this on gentoo-dev, in
> relation to 'BDEPENDS'.
>
> >Well, moving stable packages to testing also creates a misnomer.
>
> Again, do your homework. Stable packages are a subset of testing
> packages for any given arch. By specifying '~arch' in your KEYWORDS (in
> /etc/make.conf), you are actually implicitly specifying 'arch'.

This is nonsense. There are some packages that are keyworded arch for a
reason. i.e. they are different than those keyworded ~arch. If you are
saying that there is no difference, maybe you should do some homework. I
really don't think the semantic problems here are worth pursuing. If there
is a problem with calling certain ebuilds "stable", that is because there
are bugs. So what? At least once a month I find a new bug in 10.3.9, which
I installed when it was released.

> >Can someone explain what is to be gained from this that cannot be
> >achieved with automated builds (e.g. to weed out the badly broken
> >stable packages and check the deps of the ~ppc-macos packages); as well
> >as a policy to relax the "30 day" rule?
>
> What automated builds? AFAIK, we don't have an automated build system,
> and one won't exist for a Real Long Time(tm). Once it does, I'm all for
> keeping a stable branch. Until then, I find that keeping a stable branch
> is way more work than we can keep up with, for all the reasons cited in
> my previous message(s) to this list.

And I explained how to avoid pressure to "keep up", in my previous
messages. As yet, no one has responded the questions and concerns raised
there-in.

In as much as you and Lina have explained the rationale for such a
retrograde step, that rationale permits better alternatives. Either that
is because you haven't published your rationale completely, or it is
because your proposal is inferior.

I understand your predicament, I'm just trying to avoid what I see is an
over-rereaction to it. Hence the debate.

> I don't mean to sound rude, here; I apologize in advance if I do. Please
> don't take any of this personally.

No offence taken.

-f
--
gentoo-osx@gentoo.org mailing list

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


On Sep 4, 2005, at 10:01 PM, Finn Thain wrote:

>> Uh, no? The x11-libs/qt deps are indeed correct. Please do your
>> homework
>> before posting to this list; you should read up on Gentoo policy
>> about
>> DEPENDS and packages that are in 'system', such as baselayout.
>>
>
> If that is the case, shouldn't qt be hard masked? If you move
> everything
> from arch to ~arch, you will be doing a lot more of that.

I don't think you understand the difference between arch and ~arch,
nor the use of package.mask. QT is marked ~arch for several reasons
1) it compiles and works on multiple unstable systems, 2) it has not
been tested against a stable environment and has not been bug-free
for 30 days, thus it cannot be "arch". If you wish to try to use a
~arch package on an arch system, that's fine. Just don't yell when it
breaks.

>
>
>> Should Gentoo policy change, I would have absolutely no problem (and
>> would actually encourage) adding 'virtual/baselayout' to DEPENDS
>> where
>> necessary. Brian Harring has also discussed this on gentoo-dev, in
>> relation to 'BDEPENDS'.
>>
>>
>>> Well, moving stable packages to testing also creates a misnomer.
>>>
>>
>> Again, do your homework. Stable packages are a subset of testing
>> packages for any given arch. By specifying '~arch' in your
>> KEYWORDS (in
>> /etc/make.conf), you are actually implicitly specifying 'arch'.
>>
>
> This is nonsense. There are some packages that are keyworded arch
> for a
> reason. i.e. they are different than those keyworded ~arch.

Actually, they're not different. The packages are exactly the same.
"arch" designates that the package has been sufficiently tested and
bug-free for long enough to be considered "stable".

> If you are
> saying that there is no difference, maybe you should do some homework.

...

> I
> really don't think the semantic problems here are worth pursuing.
> If there
> is a problem with calling certain ebuilds "stable", that is because
> there
> are bugs. So what? At least once a month I find a new bug in
> 10.3.9, which
> I installed when it was released.

Then in my understanding of proper QA, 10.3.9 should not be "stable"
either. Seriously though, we have a lot more bugs. I am not
comfortable saying something is stable when it is clearly buggy.

>>> Can someone explain what is to be gained from this that cannot be
>>> achieved with automated builds (e.g. to weed out the badly broken
>>> stable packages and check the deps of the ~ppc-macos packages);
>>> as well
>>> as a policy to relax the "30 day" rule?
>>>
>>
>> What automated builds? AFAIK, we don't have an automated build
>> system,
>> and one won't exist for a Real Long Time(tm). Once it does, I'm
>> all for
>> keeping a stable branch. Until then, I find that keeping a stable
>> branch
>> is way more work than we can keep up with, for all the reasons
>> cited in
>> my previous message(s) to this list.
>>
>
> And I explained how to avoid pressure to "keep up", in my previous
> messages. As yet, no one has responded the questions and concerns
> raised
> there-in.

Sure, an automated system is a great idea. The problem is that it
requires a lot of work to build one. It is in the works for now, but
it's not here yet, so until then we have to deal with what we've got.
Once we have an automated system and our setup isn't as dynamic, we
can easily add support for a stable configuration.

- --Lina Pezzella
Ebuild & Porting Co-Lead
Gentoo for OS X

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDG7qXNJ9STR9DbYERAv4uAJ9uMgXW9MNrUidztGeEgFUmk0YNJwCfe97I
oVh0UxOAIEBd1/QDneSsK9g=
=/+Uo
-----END PGP SIGNATURE-----
--
gentoo-osx@gentoo.org mailing list

On Sun, 4 Sep 2005, Lina Pezzella wrote
>
> On Sep 4, 2005, at 10:01 PM, Finn Thain wrote:
>
> > >Uh, no? The x11-libs/qt deps are indeed correct. Please do your
> > >homework before posting to this list; you should read up on Gentoo
> > >policy about DEPENDS and packages that are in 'system', such as
> > >baselayout.
> > >
> >
> >If that is the case, shouldn't qt be hard masked? If you move
> >everything from arch to ~arch, you will be doing a lot more of that.
>
> I don't think you understand the difference between arch and ~arch, nor
> the use of package.mask. QT is marked ~arch for several reasons 1) it
> compiles and works on multiple unstable systems, 2) it has not been
> tested against a stable environment and has not been bug-free for 30
> days, thus it cannot be "arch". If you wish to try to use a ~arch
> package on an arch system, that's fine. Just don't yell when it breaks.

Yep, that's pretty much how I understand the difference between arch and
~arch. There is no disagreement here, but you missed my point: which
is what happens (under your ~arch proposal) when a hypothetical ~arch
qt-x.y.z breaks because I'm running a ~arch baselayout (but not the same
~arch one used when the dev keyworded qt-x.y.z with ~arch)? What happens
is this: qt breaks, i.e. similar bug report to what we have now _unless_
that qt gets hard masked.

Abandoning arch deprives you of a useful feature of portage. No-one has
indicated how that functionality might be recovered in the future.

> >
> > >Should Gentoo policy change, I would have absolutely no problem (and
> > >would actually encourage) adding 'virtual/baselayout' to DEPENDS
> > >where necessary. Brian Harring has also discussed this on gentoo-dev,
> > >in relation to 'BDEPENDS'.
> > >
> > >
> > > >Well, moving stable packages to testing also creates a misnomer.
> > > >
> > >
> > >Again, do your homework. Stable packages are a subset of testing
> > >packages for any given arch. By specifying '~arch' in your KEYWORDS
> > >(in /etc/make.conf), you are actually implicitly specifying 'arch'.
> > >
> >
> >This is nonsense. There are some packages that are keyworded arch for a
> >reason. i.e. they are different than those keyworded ~arch.
>
> Actually, they're not different. The packages are exactly the same.
> "arch" designates that the package has been sufficiently tested and
> bug-free for long enough to be considered "stable".

This is a contradiction in terms. You say, they're not different, yet one
can be considered stable and one cannot?

Again, you've missed my point (which was purely a response to your
complaint about a misnomer, i.e. a semantic issue that really is
inconsequential).

> >If you are saying that there is no difference, maybe you should do some
> >homework.
>
> ...
>
> >I really don't think the semantic problems here are worth pursuing. If
> >there is a problem with calling certain ebuilds "stable", that is
> >because there are bugs. So what? At least once a month I find a new bug
> >in 10.3.9, which I installed when it was released.
>
> Then in my understanding of proper QA, 10.3.9 should not be "stable"
> either. Seriously though, we have a lot more bugs.

I do take Mac OS X bugs seriously. FWIW, the most recent one I found was
an nasty ipfw bug that will never be fixed.

> I am not comfortable saying something is stable when it is clearly
> buggy.

There is no such thing as bug free. There is only "free of known bugs".

Now, if you relax the 30-day rule, you just change the definition of
"stable" slightly so that it becomes achievable within the limited
resources of the project. "Stable" was never anything more than a line in
the sand.

It might be useful to look at ways minor-architectures (say m68k, s390 or
BSD) cope with the limited resources problem.

> > > >Can someone explain what is to be gained from this that cannot be
> > > >achieved with automated builds (e.g. to weed out the badly broken
> > > >stable packages and check the deps of the ~ppc-macos packages); as
> > > >well as a policy to relax the "30 day" rule?
> > > >
> > >
> > >What automated builds? AFAIK, we don't have an automated build
> > >system, and one won't exist for a Real Long Time(tm). Once it does,
> > >I'm all for keeping a stable branch. Until then, I find that keeping
> > >a stable branch is way more work than we can keep up with, for all
> > >the reasons cited in my previous message(s) to this list.
> > >
> >
> >And I explained how to avoid pressure to "keep up", in my previous
> >messages. As yet, no one has responded the questions and concerns
> >raised there-in.
>
> Sure, an automated system is a great idea. The problem is that it
> requires a lot of work to build one. It is in the works for now, but
> it's not here yet, so until then we have to deal with what we've got.
> Once we have an automated system and our setup isn't as dynamic, we can
> easily add support for a stable configuration.

Automated builds address the QA problem. It is a completely seperate issue
which I probably shouldn't have raised in the context of the
s/ppc-macos/~ppc-macos/ proposal, simply because that proposal has nothing
to do with improving QA.

-f

> - --Lina Pezzella
> Ebuild & Porting Co-Lead Gentoo for OS X
--
gentoo-osx@gentoo.org mailing list

On Sat, 3 Sep 2005, Lina Pezzella wrote (in reply to Grobian):

> >The problem is happening for real at
> >http://bugs.gentoo.org/show_bug.cgi?id=87758
> >
> >there baselayout is necessary. However, baselayout is only pulled in
> >the initial "emerge system" if you use ACCEPT_KEYWORD="~ppc-macos".
> >Hence, I can't compile, because QTDIR is not set for me, while someone
> >having a complete ~ppc-macos system can. Portage won't pull the
> >dependency of baselayout for a reason I think, but the particular
> >problem sheds this light on the whole problem of how to test what on
> >which system.
>
> This is basically the basis of Hasan and my proposal to drop stable
> support for ppc-macos.

I think that if the amd team's methodology [1] had been employed, this
problem would be less important. That is, "...chroots for core packages
going from package.masked to testing..." Had the core packages been
package.masked, qt would not have been keyworded ~ppc-macos.

(One might take a broad definition of "core packages" to mean "a package
that commonly serves as an implicit dep".)

In general, it would then be safer for a stable end-user to do the
occasional emerge from ~ppc-macos (an idea I like a lot), and it would
mean that devs did not have to uniformly adopt ~ppc-macos (which is is not
great for QA), and it would mean one less reason to drop the ppc-macos
keyword (I'm trying criticise that proposal constructively, as I realise
that its motivation is important.)

-f

[1] http://groups.google.com.au/group/linux.gentoo.dev/msg/7d984fa7593f8e80?hl=en&

--
gentoo-osx@gentoo.org mailing list

Finn Thain wrote:
> In general, it would then be safer for a stable end-user to do the
> occasional emerge from ~ppc-macos (an idea I like a lot), and it would
> mean that devs did not have to uniformly adopt ~ppc-macos (which is is not
> great for QA), and it would mean one less reason to drop the ppc-macos
> keyword (I'm trying criticise that proposal constructively, as I realise
> that its motivation is important.)

Let me quote a message from -dev:

> Kevin F. Quinn wrote:
>> On 5/9/2005 13:41:54, Jason Stubbs (jstubbs@gentoo.org) wrote:
>>
>>>On Monday 05 September 2005 20:21, Simon Stelling wrote:
>>>
>>>>Ciaran McCreesh wrote:
>>>>
>>>>>If it isn't fit to be marked stable, it shouldn't be out of
>>>>>package.mask. ~arch means "candidate for going stable after more
>>>>>testing", not "might work".
>>>>
>>>>It's a bit of both. When you put a package into ~arch, it's in
>>>>"testing", so that says it needs further "testing" since there still
>>>>could be a not yet discovered bug, right?
>>>
>>>Testing of the ebuild rather than of the package, though. This is the
>>>point where people sometimes get confused.
>>
>>
>> That'd be me then :)
>>
>> So we're talking about correctness of ebuilds (correct dependencies,
>> use flag logic etc) and not whether the package actually works in depth.
>> The latter is what caused me to suggest drawing together a large team of
>> user-testers managed by arch-team devs. Correctness of ebuilds takes
>> us back to a dev role and the ebuild quiz, since it's necessary to
>> understand ebuilds to criticise them.
>>
>
> After a rather heated discussion a while back, I came up with this
> definition:
>
> - -arch :: the end-user software is/might be flakey
> ~arch :: the ebuild is/might be flakey but the software is good
> arch :: its all good :)
>
> Nathan

I was/am one of the people to have the misconception that ~arch means
the ebuild is fine (why else do I test it for in any possible situation)
but the software may be buggy.

The only difference between ~arch and arch is that the ebuild might
suck! Now it suddenly makes sense that such ebuild is being stabled
after 30 days, because the assumption is there that the software being
installed itself is stable, as upstream called it stable.

Now I don't think this particular quote should be taken as 'the law',
but it nicely shows that even on the base of Gentoo, the correct
interpretation for ~arch and arch is not really known.


--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

On Mon, 5 Sep 2005, Grobian wrote:

> I was/am one of the people to have the misconception that ~arch means
> the ebuild is fine (why else do I test it for in any possible situation)
> but the software may be buggy.
>
> The only difference between ~arch and arch is that the ebuild might
> suck!

I agree. Maybe you could add that ~arch means "ebuild is fine for at least
one combination of USE flags for at least one profile"?

What's more, an ebuild that doesn't suck in only one profile can still go
stable if it gets package.masked in the others. (Comments in package.mask
indicate that this is current practice.)

> Now it suddenly makes sense that such ebuild is being stabled after 30
> days, because the assumption is there that the software being installed
> itself is stable, as upstream called it stable.
>
> Now I don't think this particular quote should be taken as 'the law',
> but it nicely shows that even on the base of Gentoo, the correct
> interpretation for ~arch and arch is not really known.

Nathan said, "-arch :: the end-user software is/might be flakey", but this
doesn't say anything about the ebuild.

I'd like to know where the package maintainer comes into it. If the
package maintainers are keeping on top of the porting going on upstream,
they will know when an OS X bug is fixed. If they are assigned the bug,
and they release the fix, do they change the keyword from -arch to ~arch?

nano is a good example. It was masked in default-darwin/package.mask, but
could have been a -arch keyword. Once upstream fixed the bug, the bugzilla
entries fell to the macos devs because the profile was masking the fix. If
the package maintainer had marked the fix ~arch, users could have emerged
it without sending new bug reports...

-f
--
gentoo-osx@gentoo.org mailing list