On Debian and Fedora experiences

Jeff Spaleta jspaleta at gmail.com
Fri Dec 8 00:35:43 UTC 2006


On 12/7/06, Christoph Wickert <christoph.wickert at nurfuerspam.de> wrote:
> Maybe it is. But on the other hand I gave you two examples, where this
> is not the case, where there are no additional BR:s and no runtime lib
> requirements.

Your bugzilla example is a totally red-herring and the underlying
problem is not solved by Suggests at all.

The problem there is multiple applications can be used to fulfill the
baseline functionality requirement. The underlying problem is how to
best offer a default choice among equals. Suggests or Recommends
doesn't solve that at all. A Suggests or Recommends does not in fact
do anything other than state the maintainers preference to the user
and encourage the user to install the maintainers stated preference
regardless of whether or not its actually needed on the system.

How is this really all that better than what version comparisons do
now from a user standpoint? You put in a virtual provides into the
multiple applications that provide the same functionality, then you
put in an explicit requires on that virtual provide. The depsolver
programatically decides which application to pull to fill that
requires from among the equals that provide the same virtual provides
IF the user doesn't already have an application installed already that
can do the job.  if the user does have an application that provides
the functionality, no additional application is installed.  Whereas
with Suggests/Recommends there would be no way for the package
management system to know if a user already has one of the
applications installed that can be used to fill that function.
Virtual provides solve the problem of choice among equals...
suggests/recommends do not.  I see no reason to implement a
Suggests/Recommends in this situation, from an end-user perspective.
>From a maintainer control situation, it has benefit. But quite
frankly, I don't really care all that much about giving maintainers
more control over user systems.

> And I claim the opposite: Suggests/Recommends _are_not_ on shared libs
> and _are_ detected at runtime. I don't recall a single deb I had to
> rebuild.

If you want to point out a very specific detailed example that makes
sense, please by all mean do so.  My concern is making sure the people
who are talking about implementing it here, do so with appropriate
examples that make sense.  The aalib example, which dominated much of
the early motiviation in discussing Suggests/Recommends in this
thread... is completely and utterly without merit... as a point of
discussion.  I don't want to pick on Matej Cepl, but standing up aalib
as a reason to move to Suggests/Recommends
only confuses the issue, just as your bugzilla ticket does.

And this tends to happen over and over and over again when this
dicussion comes up in fedora every 6 months.  The wrong examples are
used as a point of discussion.  I have yet to see an example in this
thread which is an appropriate starting point to talk about
Suggests/Recommends that solves a real current packaging problem in
the fedora space.  I know these situations exist, I can even idenfify
examples, but I have no compelling reason to do so. I continue to be
actively hostile to Suggests/Recommends so I'm not going to go out of
my way to make it easier for people to argue for it.  But I'm more
than willing to continue a rational discussion about it, when the
people who want it as a technical solution standup a current rpm
packaging situation which is best served with Suggests/Recommends.

> I guess I wouldn't be maintaining a single package here if gentoo was
> right for me. ;)

I make no claim that you act rationally, nor do I expect you to make
rational self-consistent decisions. All I can do is point out rational
self-consistent points of view with an aim towards directing the
available development resources to make the most benefit for the
future directions of this large scale project.  I continue to think
that the amount of resources needed to implement Suggests/Recommends
is not worth the effort and I will continue to encourage developers to
spend their time working on what I view as more important technical
problems.
I am also not above blackmailing developers with promises of
mail-order Krispy Kreme doughnuts.

> IHMO yes. gstreamer-plugins would become a meta-package, that would
> require/suggest the other plugins. Why not?

Yippie!  Not just Suggests but meta-packages too. The mature handling
of meta-packages requires even more packaging infrastructure and waste
of development resources. Standing up more complexity to solve
technical defects in an already too-complex Suggests idea, is a bad
sign.

> I don't think it's a fetish and I do think it's more then 0.5%. I know
> many people who don't use fedora because our packages and the default
> install tend to be too large.

With an installed user base of at least 100,000 people, 0.5% isn't are
particularly small absolute number. Regardless, I see absolutely no
evidence that Suggests/Recommends is an appropriate technical solution
to the issue of default install size.  To me Suggests/Recommends is an
implementation idea in search of a problem to solve in the Fedora
packaging policy space. Just because Debian does it, doesn't mean its
a good idea to start using here.  I garuntee we can make real headway
on the install size of the default install scenarios without reaching
for the complexity of building tools which understand how to process
Suggests/Recommends.

> Christoph "jef is is exaggerating once again" Wickert

-jef"You misunderstand me. I'm not saying the sky is falling. I'm
saying the ground is exploding upward into the sky."spaleta




More information about the fedora-extras-list mailing list