PackageKit in Fedora 15 (beta)

[Kevin Kofler]

James Antill wrote:
>  rpm5 isn't used anywhere, so is irrelevant to any discussion on
> anything.

It's used in PLD and Ark Linux, at least. (Ark Linux is Bernhard 
Rosenkränzer's project, the ex-RH-KDE-maintainer who has just as much a 
grudge against RH as RPM5's Jeff Johnson, so it's no wonder they went with 
RPM5.)

Please also note that my proposal is explicitly NOT to adopt RPM5 in Fedora. 
It is to adopt the concept of Recommends and Suggests, nothing else.

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

That doesn't imply that soft dependencies wouldn't be just as useful to us.

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

That's a bit strange, IMHO. (See also my answer to 4.)

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

That could be discussed (and possibly implemented) later. There's no reason 
to block a decision on Recommends/Suggests on the reverse ones.

> 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.

The idea of having 2 levels is that one would be enabled by default and the 
other one wouldn't. So the decision of which level to use is simple: Do we 
want to drag this dependency in by default (but still not make it a hard 
requirement) or not? Only 1 level is suboptimal because it doesn't allow 
making this decision (but it's still better than nothing, i.e. the status 
quo). With more than 2 levels, on the other hand, the level you assign to 
the dependency starts becoming pretty arbitrary, and there would be room for 
inconsistencies across the distribution. That's why my proposal has 2 
levels. And Debian's existing naming happens to fit those 2 levels nicely, 
even though their implementation doesn't exactly correspond to my proposal.

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

Where else would you put them?

Comps? That has worse granularity (groups as opposed to packages) and 
doesn't currently work on upgrades (and I'm not convinced that the proposals 
to track comps groups as a kind of metapackages, which would make them work 
across upgrades, are a good idea).

Update metadata? How does the information get there? The metadata is 
normally generated from information in the packages or in Bodhi. The latter 
is not a solution because it doesn't cover packages in GA and because you 
don't want to have to reenter the soft dependencies each time you push an 
update. So this means the data needs to be in the packages (and the update 
metadata of course needs to carry it too, but it has to get it from the 
package headers, just like the hard dependencies).

        Kevin Kofler