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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] Mirror layout, round two
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129222020.GK21938%40mars-attacks.org%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="001522.html">
<LINK REL="Next" HREF="001510.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Mirror layout, round two</H1>
<B>nicolas vigier</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129222020.GK21938%40mars-attacks.org%3E"
TITLE="[Mageia-dev] Mirror layout, round two">boklm at mars-attacks.org
</A><BR>
<I>Mon Nov 29 23:20:20 CET 2010</I>
<P><UL>
<LI>Previous message: <A HREF="001522.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI>Next message: <A HREF="001510.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1525">[ date ]</a>
<a href="thread.html#1525">[ thread ]</a>
<a href="subject.html#1525">[ subject ]</a>
<a href="author.html#1525">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>On Mon, 29 Nov 2010, andre999 wrote:
><i> They focus on the issue in question, to varying degrees of success.
</I>><i> (Reminds me of end-user support. Much of the time they don't recognize the
</I>><i> real problem.)
</I>><i> My point is, significant bugs in core packages should be fixed in a timely
</I>><i> manner, as much as possible. And indeed, critical bugs should be fixed.
</I>><i> But if a critical bug affects a non-core package, it is likely to affect
</I>><i> only that package. Not so a core bug.
</I>
I would expect package maintainers to know wether the packages they
maintain are critical or not by themself. I don't think it would make
sense to look at the repository name to decide if it's a critical bug or
not.
>>><i> Core is proposed to be largely "base system& components". Part of the
</I>>>><i> idea is to make clearer, to everyone, which packages have an enhanced level
</I>>>><i> of support.
</I>>>><i> Support time is another (useful) question.
</I>>>><i>
</I>>><i> Why do we need two repositories for that ?
</I>>><i>
</I>><i> Sandbox.
</I>><i> It is clearer to everyone.
</I>
How is that "clearer" ? The level of support is not even displayed in
current versions of rpmdrake. And you have to click on "Details" to see
the repository name.
If we provide the list of fully supported packages separatly, we could
display the level of support in the package manager. How would that be
"less clear to everyone" ?
><i> The fact that Mandriva didn't control what went into main is a large part
</I>><i> of their problem.
</I>
Mandriva controled what went into main.
><i> If you can find another solution, just as reliable, great.
</I>><i> But I suspect it would be more complex, and probably cost more in resources
</I>><i> as well.
</I>><i> The cost of extra repositories is almost nil - if we assume that we want to
</I>><i> rigorously control what is to be fully supported, and apply it.
</I>
As already explained in this thread, the cost is not nil, and we don't
need repositories to define what is fully supported.
>>>><i> - Some packages have a lot of optional plugins, and we build them all,
</I>>>>><i> adding a lot of build requires. With main/contrib separation we need
</I>>>>><i> to add all the build dependencies to main, even if most of them are
</I>>>>><i> not runtime dependencies.
</I>>>>><i>
</I>>>><i> We will have to be more selective for core packages, to avoid this problem.
</I>>>><i> Maybe "suggests", or other features being added with rpm5.
</I>>>><i>
</I>>><i> Suggests on BuildRequires does not exists. And we need them to be
</I>>><i> installed for the build.
</I>>><i>
</I>><i> If a core package has real buildrequires, then these requires should be in
</I>><i> core.
</I>
What is "real buildrequires" ?
><i> If only a non-core package has buildrequires, these requires need not
</I>><i> necessarily be in core.
</I>><i> Although packages like cmake should probably be in core anyway, as they are
</I>><i> very likely to be used to build packages.
</I>><i> I don't know details for rpm5, but it could have the equivalent of suggests
</I>><i> for buildrequires. (Like an alternate list of tools required ?)
</I>
Suggests for buildrequires doesn't make much sense.
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="001522.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI>Next message: <A HREF="001510.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1525">[ date ]</a>
<a href="thread.html#1525">[ thread ]</a>
<a href="subject.html#1525">[ subject ]</a>
<a href="author.html#1525">[ 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>
|
