4:35 p.m.
I saw a review ticket for a package which uses Requires(missingok):
which I have not seen before. Some searching turned up the kismet and
python-docutils which currently use this idiom.
What is this actually supposed to do? I can understand what
Requires(hint) might do, but Requires(missingok) sounds more like it
wouldn't actually do anything if the dependency is not present, which
would make me wonder as to the point of having it at all.
Do we want Requires(missingok) in Fedora packages?
- J<
5:34 p.m.
On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
I saw a review ticket for a package which uses Requires(missingok):
which I have not seen before. Some searching turned up the kismet and
python-docutils which currently use this idiom.
What is this actually supposed to do? I can understand what
Requires(hint) might do, but Requires(missingok) sounds more like it
wouldn't actually do anything if the dependency is not present, which
would make me wonder as to the point of having it at all.
Do we want Requires(missingok) in Fedora packages?
no - at least for yum it is not supported.
-sv
2:28 a.m.
seth vidal wrote:
On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
> I saw a review ticket for a package which uses Requires(missingok):
> which I have not seen before. Some searching turned up the kismet and
> python-docutils which currently use this idiom.
>
> What is this actually supposed to do? I can understand what
> Requires(hint) might do, but Requires(missingok) sounds more like it
> wouldn't actually do anything if the dependency is not present, which
> would make me wonder as to the point of having it at all.
>
> Do we want Requires(missingok) in Fedora packages?
>
no - at least for yum it is not supported.
Is there any way of softdependencies supported by yum? Is this planned for the
the future, for plugin basd apps it would be nice to be able to hint to the end
user that certain optional plugins (with perhaps some hefty deps) would be good
to install, then in beginning user mode (== default) yum could treat these as
harddeps, and more advanced users could reconfigure the behavior to for example
ask the user, or just not install soft-deps.
Regards,
Hans
2:44 a.m.
On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
> I saw a review ticket for a package which uses Requires(missingok):
> which I have not seen before. Some searching turned up the kismet and
> python-docutils which currently use this idiom.
>
> What is this actually supposed to do? I can understand what
> Requires(hint) might do, but Requires(missingok) sounds more like it
> wouldn't actually do anything if the dependency is not present, which
> would make me wonder as to the point of having it at all.
>
> Do we want Requires(missingok) in Fedora packages?
>
no - at least for yum it is not supported.
Rpm doesn't support that either as of 4.4.2.x, but the parsing of
Requires(foo) attributes is somewhat broken so it doesn't report the error
as such in all cases (yes, it's a bug of course).
Requires(missingok) means just as much to rpm 4.4.2.x as
Requires(arbitraryjunk)
- Panu -
4:57 a.m.
On Mon, Mar 03, 2008 at 09:28:41AM +0100, Hans de Goede wrote:
seth vidal wrote:
> On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
>> I saw a review ticket for a package which uses Requires(missingok):
>> which I have not seen before. Some searching turned up the kismet and
>> python-docutils which currently use this idiom.
>>
>> What is this actually supposed to do? I can understand what
>> Requires(hint) might do, but Requires(missingok) sounds more like it
>> wouldn't actually do anything if the dependency is not present, which
>> would make me wonder as to the point of having it at all.
>>
>> Do we want Requires(missingok) in Fedora packages?
>>
>
> no - at least for yum it is not supported.
>
Is there any way of softdependencies supported by yum? Is this planned for
the the future, for plugin basd apps it would be nice to be able to hint to
the end user that certain optional plugins (with perhaps some hefty deps)
would be good to install, then in beginning user mode (== default) yum
could treat these as harddeps, and more advanced users could reconfigure
the behavior to for example ask the user, or just not install soft-deps.
Worth comparing what Debian do:
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
8:20 a.m.
On Mon, 2008-03-03 at 09:28 +0100, Hans de Goede wrote:
Is there any way of softdependencies supported by yum? Is this
planned for the
the future, for plugin basd apps it would be nice to be able to hint to the end
user that certain optional plugins (with perhaps some hefty deps) would be good
to install, then in beginning user mode (== default) yum could treat these as
harddeps, and more advanced users could reconfigure the behavior to for example
ask the user, or just not install soft-deps.
Since rpm doesn't support it, it doesn't really matter.
-sv
8:26 a.m.
On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
> Is there any way of softdependencies supported by yum? Is this
planned for
> the the future, for plugin basd apps it would be nice to be able to hint to
> the end user that certain optional plugins (with perhaps some hefty deps)
> would be good to install, then in beginning user mode (== default) yum
> could treat these as harddeps, and more advanced users could reconfigure
> the behavior to for example ask the user, or just not install soft-deps.
Worth comparing what Debian do:
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
you'll note debian doesn't specify behavior. So much in fact b/c, last
time I checked, apt just lists out suggests/recommends to the terminal
w/o doing anything with them.
Seriously - these are the hard questions to answer:
1. if foo suggests bar, baz and quux and the user is using -y in yum or
using kickstart to install do we:
a. automatically install them
b. automatically ignore them
c. something in between?
2. If foo suggest bar, baz, quux and the user has asked to remove foo
do we:
a. automatically remove them
b. automatically ignore them
c. something in between?
If we do A in both cases then they're just dependencies and should be
left that way.
If we do B then they're nothing to the user and don't matter
Now, the first question is: "But what about interactive modes, couldn't
you prompt and ask the user what to do?" The problem is installing rpms
is a non-interactive business and we have to have a sensible answer for
the non-interactive modes before anything else. Moreover, if we have a
sensible answer for non-interactive why would we bug the user to ask
them what to do along the way if our answer is sensible?
-sv
9:04 a.m.
On Mon, Mar 03, 2008 at 09:26:10AM -0500, seth vidal wrote:
On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
> Worth comparing what Debian do:
>
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
you'll note debian doesn't specify behavior. So much in fact b/c, last
time I checked, apt just lists out suggests/recommends to the terminal
w/o doing anything with them.
Even just listing them out is (IMHO) a good thing. Sometimes on
Debian I'll see a suggestion that looks worthwhile, kill the apt-get,
and start it again with the extra package. Of course what Debian is
then missing is an explanation of what the extra package does and why
it enhances the requested package, eg:
yum install foo
foo suggests bar
bar: with this package you will be able to foo bars as well
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
9:08 a.m.
On Mon, 2008-03-03 at 15:04 +0000, Richard W.M. Jones wrote:
On Mon, Mar 03, 2008 at 09:26:10AM -0500, seth vidal wrote:
> On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
> > Worth comparing what Debian do:
> >
> > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
>
> you'll note debian doesn't specify behavior. So much in fact b/c, last
> time I checked, apt just lists out suggests/recommends to the terminal
> w/o doing anything with them.
Even just listing them out is (IMHO) a good thing. Sometimes on
Debian I'll see a suggestion that looks worthwhile, kill the apt-get,
and start it again with the extra package. Of course what Debian is
then missing is an explanation of what the extra package does and why
it enhances the requested package, eg:
yum install foo
foo suggests bar
bar: with this package you will be able to foo bars as well
so the above does nothing for the most useful case of anaconda, then.
-sv
9:15 a.m.
On Mon, 2008-03-03 at 10:08 -0500, seth vidal wrote:
On Mon, 2008-03-03 at 15:04 +0000, Richard W.M. Jones wrote:
> On Mon, Mar 03, 2008 at 09:26:10AM -0500, seth vidal wrote:
> > On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
> > > Worth comparing what Debian do:
> > >
> > >
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
> >
> > you'll note debian doesn't specify behavior. So much in fact b/c, last
> > time I checked, apt just lists out suggests/recommends to the terminal
> > w/o doing anything with them.
>
> Even just listing them out is (IMHO) a good thing. Sometimes on
> Debian I'll see a suggestion that looks worthwhile, kill the apt-get,
> and start it again with the extra package. Of course what Debian is
> then missing is an explanation of what the extra package does and why
> it enhances the requested package, eg:
>
> yum install foo
>
> foo suggests bar
> bar: with this package you will be able to foo bars as well
>
so the above does nothing for the most useful case of anaconda, then.
I think Anaconda will have to treat soft deps as hard deps.
~spot
10:10 a.m.
>>>> "TC" == Tom \"spot\" Callaway
<Tom> writes:
TC> I think Anaconda will have to treat soft deps as hard deps.
Or it (and yum) could ignore them completely and push the entire off
to some additional application which gives you the current set of
suggestions for what you have installed.
- J<
10:13 a.m.
>>>> "PM" == Panu Matilainen
<pmatilai(a)laiskiainen.org> writes:
PM> Rpm doesn't support that either as of 4.4.2.x, but the parsing of
PM> Requires(foo) attributes is somewhat broken so it doesn't report
PM> the error as such in all cases (yes, it's a bug of course).
What really bothers me is that we already know what Requires(post),
Requires(pre) and such mean. So going by that, Requires(hint) or
Requires(missingok) would indicate a dependency for the %hint or
%missingok scriptlets. Which, uh, they don't.
I know that rpm specfile syntax isn't clean by any stretch of the
imagination, but I can't see the motivation for taking something which
actually made sense and shovelling in a load of turds for no reason.
- J<
10:16 a.m.
On Mon, 2008-03-03 at 10:13 -0600, Jason L Tibbitts III wrote:
>>>>> "PM" == Panu Matilainen
<pmatilai(a)laiskiainen.org> writes:
PM> Rpm doesn't support that either as of 4.4.2.x, but the parsing of
PM> Requires(foo) attributes is somewhat broken so it doesn't report
PM> the error as such in all cases (yes, it's a bug of course).
What really bothers me is that we already know what Requires(post),
Requires(pre) and such mean. So going by that, Requires(hint) or
Requires(missingok) would indicate a dependency for the %hint or
%missingok scriptlets. Which, uh, they don't.
I know that rpm specfile syntax isn't clean by any stretch of the
imagination, but I can't see the motivation for taking something which
actually made sense and shovelling in a load of turds for no reason.
+!
-sv
10:18 a.m.
On Mon, 2008-03-03 at 11:16 -0500, seth vidal wrote:
On Mon, 2008-03-03 at 10:13 -0600, Jason L Tibbitts III wrote:
> >>>>> "PM" == Panu Matilainen
<pmatilai(a)laiskiainen.org> writes:
>
> PM> Rpm doesn't support that either as of 4.4.2.x, but the parsing of
> PM> Requires(foo) attributes is somewhat broken so it doesn't report
> PM> the error as such in all cases (yes, it's a bug of course).
>
> What really bothers me is that we already know what Requires(post),
> Requires(pre) and such mean. So going by that, Requires(hint) or
> Requires(missingok) would indicate a dependency for the %hint or
> %missingok scriptlets. Which, uh, they don't.
>
> I know that rpm specfile syntax isn't clean by any stretch of the
> imagination, but I can't see the motivation for taking something which
> actually made sense and shovelling in a load of turds for no reason.
+!
or +1, even. you know, without the sticky shift key :/
-sv
12:41 p.m.
Jason L Tibbitts III wrote:
I saw a review ticket for a package which uses Requires(missingok):
which I have not seen before. Some searching turned up the kismet and
python-docutils which currently use this idiom.
Just a note: I've removed the missingok from python-docutils in rawhide
as it seems to be plainly wrong.
-Toshio
4:18 p.m.
On Mon 03-Mar-2008 at 09:28 +0100, Hans de Goede wrote:
Is there any way of softdependencies supported by yum? Is this planned
for the the future, for plugin basd apps it would be nice to be able to
hint to the end user that certain optional plugins (with perhaps some
hefty deps) would be good to install
Surely this information already exists in the database?
A gimp plugin already has a 'Requires: gimp', so it ought to be
possible to select the gimp in some (imaginary) GUI and be offered
add-on packages that would be useful with the gimp.
`repoquery --whatrequires gimp` really does return a good list of
add-ons, and the advantage is that the gimp packager doesn't need to
list all possible past and future plugins.
--
Bruno
5891
days inactive
5892
days old
packaging@lists.fedoraproject.org
15 comments
8 participants
participants (8)
-
Bruno Postle -
Hans de Goede -
Jason L Tibbitts III -
Panu Matilainen -
Richard W.M. Jones -
Seth Vidal -
Tom Callaway -
Toshio Kuratomi