FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 04-26-2011, 06:55 PM
Matej Cepl
 
Default Suggests/Recommends proposal

Dne 26.4.2011 18:23, Florian Festi napsal(a):
> 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.

Well, I would for starters just take
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
as a basis for the further refinement.

== Recommends ==

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found together
with this one in all but unusual installations.

== Suggests ==

This is used to declare that one package may be more useful with one or
more others. Using this field tells the packaging system and the user
that the listed packages are related to this one and can perhaps enhance
its usefulness, but that installing this one without them is perfectly
reasonable.

-----------------------------------------------------

As an examples of Recommends I heard crond (or procmail) and
/usr/sbin/sendmail ... strictly speaking crond (and procmail) work
without sendmail, but almost never seen the former without the latter,
and usually if you want that it is some very special case, where
administrator knows what he is doing.

On the other hand the case in the hand ... gnome-settings-daemon and
packagekit (or phonon-gstreamer-backend and its packagekit plugin) would
be Suggests — there are many real world scenarios where one could live
without PackageKit, but there is no discussion that PK plugin (when it
works, that is) could be very useful addition for totem or phonon.

> As soon as one looks at the details it becomes less obvious what "we
> really want". Even whether the Suggests/Recommends should live in the
> packages or in comps or else where or both or both or in all three is
> still under debate.

IMHO, Suggests/Recommends should live in the spec file and be maintained
by the package maintainers.

> Do we need reverse relations? Do we really want to
> have exactly two levels of strength? Do we need "conditionals" (install
> an package only if two or more other packages are installed) as we had
> (have) in comps? Or should be trash the whole concept of comps and comps
> groups and start all over? When and how should they be evaluated? Do we
> need to save the users decision not to want the suggested package? What
> happens if the Suggests changes during an update?

We can work on these more elaborate ideas later, but I think that the
plain introduction of the Suggests/Recommends as outlined above
(roughly, I guess there would be a lot of discussion about that even)
would be nice starter for F16 (with a lot of bugs to discuss what level
of dependency is required for each particular case). We can deal with
the esoteric cases you suggest later.

And specifically about comps ... no, I would leave them in cases where
they are useful (i.e., roughly anywhere they don't do work of S/R
dependencies). They are useful for suggesting grouping of packages and
organization of installation models (i.e., definition of what's Desktop,
what's KDE, etc.). And even then I don't think there is a need for any
rush to replace comps any time soon ... the biggest value of
Suggests/Recommends IMHO is the possibility to break unnecessary
Requires which make these nonsensical situations (i.e., you need
PackageKit in order to have gdm).

> So I am not too optimistic that we'll have Suggests or
> Recommends any time soon.

As I said above I have been saying this for almost five years already.
It took Cato the Elder fifty years, so I think I have still some way to
go

>[*] Depending on the exact features implementing still can be tricky and
> require a lot of work. I doubt that it will be even remotely close to
> half an hour but nothing that cannot be handled.

Of course, I expect that it was half an hour used in a Pickwickian manner.

Best,

Matěj

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-27-2011, 08:07 AM
"tim.lauridsen@gmail.com"
 
Default Suggests/Recommends proposal

On Tue, Apr 26, 2011 at 8:55 PM, Matej Cepl <mcepl@redhat.com> wrote:

Dne 26.4.2011 18:23, Florian Festi napsal(a):

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



Well, I would for starters just take

http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

as a basis for the further refinement.



== Recommends ==



This declares a strong, but not absolute, dependency.



The Recommends field should list packages that would be found together

with this one in all but unusual installations.



== Suggests ==



This is used to declare that one package may be more useful with one or

more others. Using this field tells the packaging system and the user

that the listed packages are related to this one and can perhaps enhance

its usefulness, but that installing this one without them is perfectly

reasonable.



-----------------------------------------------------



As an examples of Recommends I heard crond (or procmail) and

/usr/sbin/sendmail ... strictly speaking crond (and procmail) work

without sendmail, but almost never seen the former without the latter,

and usually if you want that it is some very special case, where

administrator knows what he is doing.



On the other hand the case in the hand ... gnome-settings-daemon and

packagekit (or phonon-gstreamer-backend and its packagekit plugin) would

be Suggests — there are many real world scenarios where one could live

without PackageKit, but there is no discussion that PK plugin (when it

works, that is) could be very useful addition for totem or phonon.



> As soon as one looks at the details it becomes less obvious what "we

> really want". Even whether the Suggests/Recommends should live in the

> packages or in comps or else where or both or both or in all three is

> still under debate.



IMHO, Suggests/Recommends should live in the spec file and be maintained

by the package maintainers.



> Do we need reverse relations? Do we really want to

> have exactly two levels of strength? Do we need "conditionals" (install

> an package only if two or more other packages are installed) as we had

> (have) in comps? Or should be trash the whole concept of comps and comps

> groups and start all over? When and how should they be evaluated? Do we

> need to save the users decision not to want the suggested package? What

> happens if the Suggests changes during an update?



We can work on these more elaborate ideas later, but I think that the

plain introduction of the Suggests/Recommends as outlined above

(roughly, I guess there would be a lot of discussion about that even)

would be nice starter for F16 (with a lot of bugs to discuss what level

of dependency is required for each particular case). We can deal with

the esoteric cases you suggest later.



And specifically about comps ... no, I would leave them in cases where

they are useful (i.e., roughly anywhere they don't do work of S/R

dependencies). They are useful for suggesting grouping of packages and

organization of installation models (i.e., definition of what's Desktop,

what's KDE, etc.). And even then I don't think there is a need for any

rush to replace comps any time soon ... the biggest value of

Suggests/Recommends IMHO is the possibility to break unnecessary

Requires which make these nonsensical situations (i.e., you need

PackageKit in order to have gdm).



> So I am not too optimistic that we'll have Suggests or

> Recommends any time soon.



As I said above I have been saying this for almost five years already.

It took Cato the Elder fifty years, so I think I have still some way to

go



>[*] Depending on the exact features implementing still can be tricky and

> require a lot of work. I doubt that it will be even remotely close to

> half an hour but nothing that cannot be handled.



Of course, I expect that it was half an hour used in a Pickwickian manner.



Best,



Matěj



--

devel mailing list

devel@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/devel
The hard part is to define what the package tools should do in the different cases
A depsolver need to work with real requirements, so it need to be defined in what cases that a soft requirement will become a real*requirements*to do the right thingAnd 2 kind of soft deps don't make it more simple.
There is lot of actions you can do in a yum transaction : install,update,remove,downgrade,obsolete,reinstall and you can mix them in a single transaction so it gets very complex.
Another issue is that**Suggests/Recommends is a parent -> child relations
When having a package there supports some kind of plugin infrastructure, you have to add recommends for all plugin packages, so each time a new plugin package is added you have to change and rebuild the main package to have a relationship, In that case it would be smarter to have a child -> parent relationship, but that would be very hard to work with if stored in the child spec only, you need some kind of central metadata to handle that.

Tim

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-27-2011, 06:47 PM
Kevin Kofler
 
Default Suggests/Recommends proposal

tim.lauridsen@gmail.com wrote:
> The hard part is to define what the package tools should do in the
> different cases
> A depsolver need to work with real requirements, so it need to be defined
> in what cases that a soft requirement will become a real requirements to
> do the right thing

See my proposal.

> And 2 kind of soft deps don't make it more simple.

See my reply to James Antill for why 2.

> Another issue is that Suggests/Recommends is a parent -> child relations
> When having a package there supports some kind of plugin infrastructure,
> you have to add recommends for all plugin packages, so each time a new
> plugin package is added you have to change and rebuild the main package to
> have a relationship, In that case it would be smarter to have a child ->
> parent relationship,

That can be discussed as a separate proposal later. Having reverse
dependencies is not a requirement for having regular soft dependencies.

> but that would be very hard to work with if stored in the child spec only,
> you need some kind of central metadata to handle that.

We already have such metadata: the repodata! Createrepo can extract that
information from the child RPM and index it by the parent RPM name.

But again, we should get forward soft dependencies working first before we
even start discussing reverse ones. It is obvious that the reverse case is
more complicated, and there is no practical need for blocking the forward
case on it.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-27-2011, 08:32 PM
Stephen John Smoogen
 
Default Suggests/Recommends proposal

On Wed, Apr 27, 2011 at 12:47, Kevin Kofler <kevin.kofler@chello.at> wrote:
> tim.lauridsen@gmail.com wrote:
>> The hard part is to define what the package tools should do in the
>> different cases
>> A depsolver need to work with real requirements, so it need to be defined
>> in what cases that a soft requirement will become a real requirements to
>> do the right thing
>
> See my proposal.
>

My problem with your proposal is that it is not crazy enough. It is a
lot of work for marginal gain and doesn't really bet the farm enough.
I would prefer a proposal that Fedora 17 will be based off of Conary
or .debs as it is crazy enough to work.

--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 01:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org