1 |
Am Samstag, 30. September 2006 19:02 schrieb Jakub Moc: |
2 |
> Mike Frysinger wrote: |
3 |
> > seriously jakub, stop responding ... you have nothing technical to |
4 |
> > offer to the issue at hand |
5 |
> > |
6 |
> > let the people who work on portage handle it |
7 |
> > -mike |
8 |
> |
9 |
> Eh, the whole technical point here is that paludis behaviour differs |
10 |
> from portage (and differs from pkgcore, FWIW). |
11 |
This has little to do with why this change to the devmanual has been |
12 |
done. |
13 |
|
14 |
> So, hiding the inconsistency via altering the profiles doesn't change |
15 |
> anything. Plus, the point of the bug's flame fest was that bugzilla |
16 |
> is not a proper place to request such behaviour changes, and |
17 |
> definitely not a reason for QA to mess with the profiles. Sticking |
18 |
> the stuff in package.mask won't make the inconsistent behaviour |
19 |
> vanish in any way, it will just hide it. |
20 |
It is not a behaviour change imho. The "packages" file changed |
21 |
its meaning subtly after introducing cascading profiles. |
22 |
As ciaranm already pointed out: It is not meant to mask "<"-like |
23 |
versions anymore. It's meant to |
24 |
- Describe the system package set |
25 |
- Define which versions are _at least_ needed for a profile. |
26 |
|
27 |
> So, I'd kinda appreciate if concerned folks (including portage and |
28 |
> relevant affected arches) were involved in this discussion, instead |
29 |
> of sneaking the changes in under QA disguise. |
30 |
Release engineering arch coordinators, which happen to be the people who |
31 |
maintain the profiles below default-linux/ for their relevant arches, |
32 |
have been CCed and Chris already stated that he forgot/didn't realize |
33 |
to fix this problem for no-nptl/2.4's package.mask. |
34 |
|
35 |
Jakub: Please reevaluate the behaviour you showed on both the bug and |
36 |
this mailing list. I for one don't consider it anywhere near |
37 |
appropriate. This shall be no offense, just a comment in regard that |
38 |
you can do better. |
39 |
|
40 |
Danny |
41 |
-- |
42 |
Danny van Dyk <kugelfang@g.o> |
43 |
Gentoo/AMD64 Project, Gentoo Scientific Project |
44 |
-- |
45 |
gentoo-dev@g.o mailing list |