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
|
Doesn't packagekit provide Gnome and KDE-native interfaces for package management?<div><br></div><div>Shawn<br><br><div class="gmail_quote">On Tue, Sep 28, 2010 at 5:47 PM, Richard <span dir="ltr"><<a href="mailto:richard.j.walker@ntlworld.com">richard.j.walker@ntlworld.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Tuesday 28 September 2010 23:42:21 Renaud MICHEL wrote:<br>
> No, if you are talking about rpmdrake, you should compare it to synaptic.<br>
> I you want to talk about apt (be it apt-get or aptitude), you should<br>
> compare it to urpmi, and urpmi (in my opinion) is not slow.<br>
><br>
</div>Agreed. Though I am not by any means a command line junkie I will always use<br>
uprmi when I know exactly what I want.<br>
<br>
So it is synaptic/apt and rpmdrake/urpmi. No doubt yum has a GUI counterpart<br>
too.<br>
<div class="im">><br>
> emerge and macports are source-based "packet" managers.<br>
> As the programs are compiled when you want to install them, you can decide<br>
> to exclude some optional, compile-time functionality, and avoid their<br>
> dependencies.<br>
><br>
> In pre-compiled packets (like rpm or deb), the packager decided what should<br>
> be compiled, and so what are the required dependencies.<br>
> You still have the option to get the source package and tweak it (via the<br>
> spec file for rpm, or rule for deb) to exclude some things you don't<br>
> require. (but you will need to do it again each time an update is<br>
> available)<br>
><br>
</div>Right, I have done this with a custom ffmpeg build. Compile time dependency<br>
control is, of course, a grace and favour benefit provided by the program<br>
author. I get the impression that a packager can introduce depencies when<br>
special support is needed for extra features he may choose to include. This<br>
seems to be what happened with the 2010.1 issue of the foobillard rpm where a<br>
new dependency on Pulse has been created which does not exist in the 2010.0<br>
package or the author's source.<br>
<div class="im">><br>
> Packages have dependencies, those are interpreted as "this package cannot<br>
> work without those".<br>
> You can also have less strict recommendations, deb has provided for long<br>
> recommended packages (not really required, but a must have) and suggested<br>
> packages (is an interesting addition, but nothing essential).<br>
> Rpm also provide such a mechanism (though I think is younger than deb) with<br>
> the suggested packages.<br>
> Urpmi take the suggested packages into account, when installing it will by<br>
> default selected also the suggested packages, but you can add the --no-<br>
> suggests option to avoid this.<br>
</div>Does this mean that I can find the KDE packages which "depend" on Pulse and<br>
re-package them such that Pulse is only "recommended"? If so then I will have<br>
to find the way to set the --no-suggests option in rpmdrake. I hadn't even<br>
looked for it before as I have only recently started to discover problems in<br>
Mandriva packages.<br>
<div class="im">> On the urpme side, if you uninstall a package that was installed as a<br>
> suggestion, it won't trigger the uninstallation of the package that<br>
> suggested it.<br>
</div>Something similar seems to apply to packages which I inadvertently "mark" as<br>
manually installed. urpme reports that such packages will be excluded from<br>
orphan detection. I love the --auto-orphans switch.<br>
<font color="#888888"><br>
Richard<br>
<br>
</font></blockquote></div><br></div>
|
