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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
