PackageKit in Fedora 15 (beta)

James Antill james at fedoraproject.org
Tue Apr 26 17:55:50 UTC 2011


On Tue, 2011-04-26 at 19:23 +0200, Kevin Kofler wrote:
> Florian Festi wrote:
> > I think if anybody can come up with a exact description how they should
> > look like and how they should work and can create some evidence that
> > this is want we need and want implementing them is not the problem[*].
> > Until now no one has come up with a proposal and enough confidence.
> 
> The proposal is this:

 Please read Florian's email again, and attempt to answer some/most of
the questions (a rationale for your answers might be nice too).
 It should have been obvious to you that a proposal like this would have
been discussed before.

> We would have 3 levels of dependencies:
> Requires: = always required
> Recommends: = required by default
> Suggests: = not required by default
[...]
> The evidence that this is what we need: This is basically how all the 
> existing implementations (deb, rpm5 etc.) I know of work and they've been 
> found to work quite well for the distros using them.

 rpm5 isn't used anywhere, so is irrelevant to any discussion on
anything.
 apt+aptitude+deb does use something like the above, with the very
significant differences of:

1. Debian with deb+apt packaging is vastly different to Fedora rpm+yum
packaging.

2. apt-get doesn't do anything, by default.

3. deb also has the two level reverse "soft requires".

4. If you talk to random debian people nobody knows why they have two
levels, what use it is over a single level (or, if it's really better,
why not three) ... and which level is signified by recommends or
suggests (or enhances/extends). Much like rpm/yum developers.

5. Even given #1, it's far from obvious that baking these assumptions
into the packages themselves is a win.

 SuSE with rpm+zypper does have recommends/suggests, and is "somewhat"
close to rpm+yum (kind of). But I don't know how much it is used ... and
I don't know what it's behaviour is. I also don't know what problems
they solve with it, and how well it solves them.



More information about the devel mailing list