1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-4.mga2
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20%5Bchangelog%5D%20%5BRPM%5D%20cauldron%20core/release%0A%09task-gnome-3.3.2-4.mga2&In-Reply-To=%3C4F3952F2.7040405%40laposte.net%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="011911.html">
<LINK REL="Next" HREF="011914.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-4.mga2</H1>
<B>andre999</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20%5Bchangelog%5D%20%5BRPM%5D%20cauldron%20core/release%0A%09task-gnome-3.3.2-4.mga2&In-Reply-To=%3C4F3952F2.7040405%40laposte.net%3E"
TITLE="[Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-4.mga2">andre999mga at laposte.net
</A><BR>
<I>Mon Feb 13 19:14:10 CET 2012</I>
<P><UL>
<LI>Previous message: <A HREF="011911.html">[Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-4.mga2
</A></li>
<LI>Next message: <A HREF="011914.html">[Mageia-dev] Beta 1 isos
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#11912">[ date ]</a>
<a href="thread.html#11912">[ thread ]</a>
<a href="subject.html#11912">[ subject ]</a>
<a href="author.html#11912">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Michael Scherer a écrit :
><i> Le lundi 13 février 2012 à 10:35 +0100, Thierry Vignaud a écrit :
</I>><i>
</I>>><i> On 13 February 2012 10:05, Olav Vitters<<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">olav at vitters.nl</A>> wrote:
</I>>><i>
</I>>>>><i> - Suggests drakconf in minimal package
</I>>>>><i>
</I>>>><i> Why as part of task-gnome*, shouldn't it be a require elsewhere?
</I>>>><i>
</I>>><i> 1) for symmetry with task-kde4-minimal
</I>>><i> It should be done in task-{lxde,xfce,..} of course
</I>>><i>
</I>><i> Then it should be documented, because currently, task-* is polluted.
</I>><i> Since everybody add his pet peeves packages as task-*, that cause the
</I>><i> same problem that was intended to solve, ie too much choice. People have
</I>><i> the warm fuzzy feeling of having a selected and taylored set of rpm, but
</I>><i> that's far from the truth.
</I>><i>
</I>
Right.
><i> Also, it abuses suggests and interact in a weird way with auto-orphans
</I>><i> ( or it should be better to say that it make it dangerous for users to
</I>><i> use the feature, thanks to the lack of semantics for Suggests, coupled
</I>><i> with lack of clear semantics on task-* and the abuse of the 2nd one by
</I>><i> the first one coupled with a too simple UI ).
</I>><i>
</I>><i>
</I>>><i> 2) so that people performing minimal install then installing task-foobar
</I>>><i> got mcc too
</I>>><i> (it's done at installer time through rpmsrate which is not used after
</I>>><i> installation by urpmi -- else nothing will pull it[1])
</I>>><i>
</I>><i> So basically, that's duplication of information ?
</I>><i>
</I>><i>
</I>>><i> 3) because that's the right place to do it
</I>>><i>
</I>>><i> Note it's a suggests, not a hard requires
</I>>><i>
</I>><i> Suggests semantics are still unclear. For now, that's "let me use this
</I>><i> to push totally unrelated packages in the default setup because I think
</I>><i> they should be installed but I have no way to explain why, and they are
</I>><i> important but not important enough to be documented or selected at
</I>><i> runtime". And that's far from being ideal.
</I>><i>
</I>
I have exactly the same impression.
It gets messy to clean up unwanted packages.
><i> In fact, the more I can think of, the more I wonder what was the problem
</I>><i> we wanted to solve with Suggests, and if we really did. The UI is near 0
</I>><i> and will be for a long time, since there isn't enough expressiveness in
</I>><i> a rpm tag for that. Advanced users, who are concerned with deps and what
</I>><i> is installed either remove suggests ( my case, because it pull lots of
</I>><i> unneeded stuff ), or just do without it for finding related packages
</I>><i> ( because you still need to look on why something is pulled, and you
</I>><i> cannot really select ( not that asking a 100 questions would be good
</I>><i> OTOH )).
</I>><i>
</I>><i> Less advanced users do not care at all about suggests in the best case
</I>><i> ( ie, it solved almost nothing for them ), and end with auto-orphans
</I>><i> doing weird stuff. It also have a weird interaction model on upgrade
</I>><i> ( like "if task-kde4 is installed, do I want to also pull all suggests,
</I>><i> even those I removed, or do I want to not do it, and then end with a
</I>><i> different result than from a fresh installation" )
</I>><i>
</I>><i> So I would suggests ( no pun intended ) to just drop them. Keeping them
</I>><i> make us diverge from upstream, afaik, requires various hack with some
</I>><i> side effect and extra documentation for almost nothing ( ie, since we
</I>><i> may not have solved a real problem ), and think to do think another way.
</I>><i>
</I>><i>
</I>This discussion reminds me of a model I'd like to see for task packages.
Thinking of rpmdrake.
Task packages show a tree of the packages to be installed.
Each required package simply shows a link to its' description. (As one
sees now for required packages.)
Each suggested package package shows justifying description line, in
addition to a link to its' description. And a check box to deselect the
item, so it is not installed.
So for example we wouldn't need a separate task-gnome and
task-gnome-minimal, since task-gnome would have everything more than
minimal as an option (or suggest).
We would have to have some means to indicate suggests already installed,
among other factors.
Although I see this model as primarily useful for task packages, it
could apply to any package with requires or suggests.
The concept is not new, it at least used to exist in the Microsoft
environment for larger packages.
Just an idea :)
--
André
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="011911.html">[Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-4.mga2
</A></li>
<LI>Next message: <A HREF="011914.html">[Mageia-dev] Beta 1 isos
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#11912">[ date ]</a>
<a href="thread.html#11912">[ thread ]</a>
<a href="subject.html#11912">[ subject ]</a>
<a href="author.html#11912">[ author ]</a>
</LI>
</UL>
<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
mailing list</a><br>
</body></html>
|
