Puppet users - Feb 2007 - Removing circular dependant RPM files with Package.

Hello,

I just attempted to remove both the ypbind and the yp-tools packages using the
package parameter with yum.  As it turns out, both of these packages depend on
each other.

Is there a way of forcing package removal and, if there is not, is there a way
of making all packages to be removed be collapsed into the same yum command? 
Either of these solutions would solve the problem with the second being safer
but more prone to failing an entire command.

The most elegant solution would be to be able to create a dependency chain
denoting the packages that should be manipulated together.

Thank you,

-- Rob --




 
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Feb 6, 2007, at 10:06 AM, Robert Mombro wrote:
> Hello,
>
> I just attempted to remove both the ypbind and the yp-tools  
> packages using the package parameter with yum.  As it turns out,  
> both of these packages depend on each other.
>
> Is there a way of forcing package removal and, if there is not, is  
> there a way of making all packages to be removed be collapsed into  
> the same yum command?  Either of these solutions would solve the  
> problem with the second being safer but more prone to failing an  
> entire command.
Currently, there is no way to do either of these.  I will say that  
you''ve got some pretty broken packages if they depend on each other.
> The most elegant solution would be to be able to create a  
> dependency chain denoting the packages that should be manipulated  
> together.
I agree, but I haven''t had the time it would take to make this work,  
especially for all the different package providers.

  --
  Measure with a micrometer.  Mark with chalk.  Cut with an axe.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On Tue, 2007-02-06 at 11:46 -0600, Luke Kanies wrote:
> Currently, there is no way to do either of these.  I will say that  
> you''ve got some pretty broken packages if they depend on each
other.
Circular dependencies between packages is actually fairly common; I just
fear that solving that in puppet will force it to implement quite a few
features of package managers.

David

Interesting.

Most of the file managers that I have used have a ''force''-like
option, would
just passing this be a possibility.

Thanks,

Trevor

On 2/6/07, David Lutterkort <dlutter@redhat.com>
wrote:
>
> On Tue, 2007-02-06 at 11:46 -0600, Luke Kanies wrote:
> > Currently, there is no way to do either of these.  I will say that
> > you''ve got some pretty broken packages if they depend on each
other.
>
> Circular dependencies between packages is actually fairly common; I just
> fear that solving that in puppet will force it to implement quite a few
> features of package managers.
>
> David
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Feb 6, 2007, at 4:17 PM, David Lutterkort wrote:
>
> Circular dependencies between packages is actually fairly common; I  
> just
> fear that solving that in puppet will force it to implement quite a  
> few
> features of package managers.
It seems like Puppet needs to start doing something to multiplex  
package operations, which (at the least) means that providers need to  
be modified to either support this ability or to declare that they  
don''t.

This multiplexing stuff is a big departure from how transactions work  
right now, though, so it''s not a small feat.

This problem definitely needs to be solved, but I don''t really know  
how.  Recommendations are appreciated.

As to circular dependencies being popular... I still maintain they''re  
silly, even if they''re common.  Windows is popular, yet...

  --
  Anyone who considers arithmatical methods of producing random digits
  is, of course, in a state of sin.    --John Von Neumann
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On Feb 7, 2007, at 12:21 PM, Trevor Vaughan wrote:
> Interesting.
>
> Most of the file managers that I have used have a
''force''-like
> option, would just passing this be a possibility.
This is probably a good idea.

  --
  The Roman Rule
          The one who says it cannot be done should never interrupt the
          one who is doing it.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On Wed, 2007-02-07 at 13:21 -0500, Trevor Vaughan wrote:
> Most of the file managers that I have used have a
''force''-like option,
> would just passing this be a possibility.
No. That would leave your system in a semi-installed state. It might
make more sense to add a parameter to the package type that lets you
indicate whether removal of a package also removes its dependencies
(that''s what this cyclical business boils down to)

For the yum provider, that would mean running ''yum erase''
instead of
''rpm -e''

David

Wouldn''t it be straightforward to just use yum to remove as well. I
haven''t
figured out why, but when provider => yum, installation is done via yum, but
removal is done via rpm.
I''m sure I''m missing something, but if I''m not, then
simply changing that
would work.

-Ezra

On 2/7/07, Luke Kanies <luke@madstop.com> wrote:
>
> On Feb 7, 2007, at 12:21 PM, Trevor Vaughan wrote:
>
> > Interesting.
> >
> > Most of the file managers that I have used have a
''force''-like
> > option, would just passing this be a possibility.
>
> This is probably a good idea.
>
>   --
>   The Roman Rule
>           The one who says it cannot be done should never interrupt the
>           one who is doing it.
>   ---------------------------------------------------------------------
>   Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>
>
>

-- 
-Ezra Mound

System Administrator
Motionbox.com
646-290-8502
ezra.mound@motionbox.com


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Luke Kanies <luke@madstop.com> writes:
> As to circular dependencies being popular... I still maintain
they''re
> silly, even if they''re common.  Windows is popular, yet...
One of the reasons why they''re so common is that if the package
management
tools handle them well, they have some nice properties.  In Debian, this
comes up all the time, most commonly with foo and foo-common packages,
where foo is arch-specific and foo-common contains a bunch of shared
cross-arch data.  Debian splits such packages to save archive space and
not duplicate the cross-arch data across every architecture.  foo has to
depend on foo-common, since otherwise it won''t run.  foo-common
doesn''t
*technically* have to depend on foo, but ideally when you remove foo (the
package name that users actually know about and care about), you want
foo-common to go away as well.

Obviously, there are other ways to solve this in the package manager (by,
for instance, tagging foo-common in some way that says it should be
removed if foo isn''t around), but if the package manager breaks
circular
dependencies in a sane fashion (which Debian''s do), a circular
dependency
looks like a nice, clean, and simple way of handling this.  So people keep
using it and don''t understand why they shouldn''t.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

On Feb 7, 2007, at 6:50 PM, Russ Allbery wrote:
>
> One of the reasons why they''re so common is that if the package  
> management
> tools handle them well, they have some nice properties.  In Debian,  
> this
> comes up all the time, most commonly with foo and foo-common packages,
> where foo is arch-specific and foo-common contains a bunch of shared
> cross-arch data.  Debian splits such packages to save archive space  
> and
> not duplicate the cross-arch data across every architecture.  foo  
> has to
> depend on foo-common, since otherwise it won''t run.  foo-common  
> doesn''t
> *technically* have to depend on foo, but ideally when you remove  
> foo (the
> package name that users actually know about and care about), you want
> foo-common to go away as well.
>
> Obviously, there are other ways to solve this in the package  
> manager (by,
> for instance, tagging foo-common in some way that says it should be
> removed if foo isn''t around), but if the package manager breaks  
> circular
> dependencies in a sane fashion (which Debian''s do), a circular  
> dependency
> looks like a nice, clean, and simple way of handling this.  So  
> people keep
> using it and don''t understand why they shouldn''t.
Okay.  Can you think of a good way to solve the problems that  
Puppet''s having, then?  Should I just support a "force"
parameter, or
is there something more meaningful I can do?

About the only thing I can think of is enhancing all of the providers  
so that they are able to operate on multiple packages at once (which  
shouldn''t be too complicated, although I expect that there would be  
annoying differences between packaging systems).

The big complication there for me is how this interacts with ordering  
during transactions.  I can pretty much guarantee that we''re going to  
end up with people wanting to delete some packages and install others  
during the same run, and compacting multiple operations will always  
be pretty darn difficult.  I guess I could try to set it up so  
package operations will operate on all packages adjacent to each  
other that have the same ''ensure'' value, and then maybe
provide a
''compact'' parameter that could be used to disable compacting
for that
package.

I don''t at all think this would be easy, and it would almost  
definitely need to be set up as a generic ability, not just something  
that packages could do (i.e., transactions would be able to compact  
any resource that supported it, but packages would likely be the only  
resource to initially do so).  This is not a big priority for me, and  
I think it would be painfully complicated.

Does that make any sense?  Anyone have any better ideas?

  --
                          ACHTUNG!!!

  Das machine is nicht fur gefingerpoken und mittengrabben.  Ist easy
  schnappen der springenwerk, blowenfusen und corkenpoppen mit
  spitzensparken.  Ist nicht fur gewerken by das dummkopfen.  Das
  rubbernecken sightseeren keepen hands in das pockets.  Relaxen und
  vatch das blinkenlights!!!
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On Feb 7, 2007, at 4:23 PM, Ezra Mound wrote:
> Wouldn''t it be straightforward to just use yum to remove as well.
I
> haven''t figured out why, but when provider => yum, installation
is
> done via yum, but removal is done via rpm.
> I''m sure I''m missing something, but if I''m not,
then simply
> changing that would work.
I assume it would be straightforward to use yum to do the removal; I  
don''t use yum, but maybe David Lutterkort could update the provider  
to do so.

  --
  Chase after truth like hell and you''ll free yourself, even though
  you never touch its coat-tails.       -- Clarence Darrow
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Luke Kanies <luke@madstop.com> writes:
> Okay.  Can you think of a good way to solve the problems that
Puppet''s
> having, then?  Should I just support a "force" parameter, or is
there
> something more meaningful I can do?
Well, with the aptitude provider, removing one package should just remove
the other one without much difficulty.  I think this logic for correctly
dealing with circular dependencies ideally belongs in the package manager.

Performing multiple package operations at the same time is appealing,
though, if on no other grounds than simply being faster when there are
multiple changes to be made.  I don''t know if that will resolve the
specific problem with yum; aptitude shouldn''t care.

One thing that I would encourage you *not* to spend too much effort on,
though, is attempting to duplicate the functionality of a package manager
in Puppet.  It''s nice to have the simple capability of installing a
package, but for instance we generate Debian packages for our major
services and put all the dependencies for the service into that package,
rather than trying to encapsulate that in Puppet.  Not only does the
package provide a convenient place to put scripts and programs,
diversions, alternatives, and other such packaging infrastructure, but it
means that we can use the full richness of versioned Depends, versioned
Conflicts, Replaces, and the apt dependency engine to make the right thing
happen.  That represents a lot of code, a lot of dependency resolution,
and a lot of work tailored to the specific distribution.  Unless someone
was working extensively on copying that sort of functionality, Puppet
would at best provide a meager shadow.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

On Feb 8, 2007, at 12:33 AM, Russ Allbery wrote:
>
> Well, with the aptitude provider, removing one package should just  
> remove
> the other one without much difficulty.  I think this logic for  
> correctly
> dealing with circular dependencies ideally belongs in the package  
> manager.
*whew* :)
> Performing multiple package operations at the same time is appealing,
> though, if on no other grounds than simply being faster when there are
> multiple changes to be made.  I don''t know if that will resolve
the
> specific problem with yum; aptitude shouldn''t care.
Yeah, compaction should speed packaging up quite a bit, especially  
for yum.  At the least, the providers could now use prefetching to  
retrieve all package information in one run, which would be quite a  
bit faster.
> One thing that I would encourage you *not* to spend too much effort  
> on,
> though, is attempting to duplicate the functionality of a package  
> manager
> in Puppet.  It''s nice to have the simple capability of installing
a
> package, but for instance we generate Debian packages for our major
> services and put all the dependencies for the service into that  
> package,
> rather than trying to encapsulate that in Puppet.  Not only does the
> package provide a convenient place to put scripts and programs,
> diversions, alternatives, and other such packaging infrastructure,  
> but it
> means that we can use the full richness of versioned Depends,  
> versioned
> Conflicts, Replaces, and the apt dependency engine to make the  
> right thing
> happen.  That represents a lot of code, a lot of dependency  
> resolution,
> and a lot of work tailored to the specific distribution.  Unless  
> someone
> was working extensively on copying that sort of functionality, Puppet
> would at best provide a meager shadow.
I agree with this, and if anything I would only like to be able to  
reuse this information, not attempt to duplicate it.

I''m all about using existing information stores, not creating a new,  
redundant one.

  --
  Hoare''s Law of Large Problems:
     Inside every large problem is a small problem struggling to get  
out.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

I think that what has been posted is correct, you should use the package
manager whenever possible.

That said, I would still like to see a basic ''force'' option
for the cases
where yum says that I can''t do something because it''s part of
the base
distro (like uninstalling cups) when I know for sure that I can.

That said, it seems like it''s a very minor issue when compared with the
yum/apt/emerge/whatever vs. rpm/whatever argument.

Also, I just found out that the existance of both a yumrepo object and a
package statement do not order correctly by default.

In every run that I tried, the yumrepo object was applied after the package
object unless explicitly told not to.

It would seem to me that the correct behaviour would be to ensure that
repo/store objects are always applied before the package statements.

In that vein, is it possible to do something like: Package { require =>
Yumrepo[] } to require all instances of Yumrepo for every Package?

Thanks,

Trevor

On 2/8/07, Luke Kanies <luke@madstop.com> wrote:
>
> On Feb 8, 2007, at 12:33 AM, Russ Allbery wrote:
> >
> > Well, with the aptitude provider, removing one package should just
> > remove
> > the other one without much difficulty.  I think this logic for
> > correctly
> > dealing with circular dependencies ideally belongs in the package
> > manager.
>
> *whew* :)
>
> > Performing multiple package operations at the same time is appealing,
> > though, if on no other grounds than simply being faster when there are
> > multiple changes to be made.  I don''t know if that will
resolve the
> > specific problem with yum; aptitude shouldn''t care.
>
> Yeah, compaction should speed packaging up quite a bit, especially
> for yum.  At the least, the providers could now use prefetching to
> retrieve all package information in one run, which would be quite a
> bit faster.
>
> > One thing that I would encourage you *not* to spend too much effort
> > on,
> > though, is attempting to duplicate the functionality of a package
> > manager
> > in Puppet.  It''s nice to have the simple capability of
installing a
> > package, but for instance we generate Debian packages for our major
> > services and put all the dependencies for the service into that
> > package,
> > rather than trying to encapsulate that in Puppet.  Not only does the
> > package provide a convenient place to put scripts and programs,
> > diversions, alternatives, and other such packaging infrastructure,
> > but it
> > means that we can use the full richness of versioned Depends,
> > versioned
> > Conflicts, Replaces, and the apt dependency engine to make the
> > right thing
> > happen.  That represents a lot of code, a lot of dependency
> > resolution,
> > and a lot of work tailored to the specific distribution.  Unless
> > someone
> > was working extensively on copying that sort of functionality, Puppet
> > would at best provide a meager shadow.
>
> I agree with this, and if anything I would only like to be able to
> reuse this information, not attempt to duplicate it.
>
> I''m all about using existing information stores, not creating a
new,
> redundant one.
>
>   --
>   Hoare''s Law of Large Problems:
>      Inside every large problem is a small problem struggling to get
> out.
>   ---------------------------------------------------------------------
>   Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Feb 8, 2007, at 6:09 AM, Trevor Vaughan wrote:
> I think that what has been posted is correct, you should use the  
> package manager whenever possible.
>
> That said, I would still like to see a basic ''force''
option for the
> cases where yum says that I can''t do something because
it''s part of
> the base distro (like uninstalling cups) when I know for sure that  
> I can.
>
> That said, it seems like it''s a very minor issue when compared
with
> the yum/apt/emerge/whatever vs. rpm/whatever argument.
>
> Also, I just found out that the existance of both a yumrepo object  
> and a package statement do not order correctly by default.
>
> In every run that I tried, the yumrepo object was applied after the  
> package object unless explicitly told not to.
>
> It would seem to me that the correct behaviour would be to ensure  
> that repo/store objects are always applied before the package  
> statements.
>
> In that vein, is it possible to do something like: Package  
> { require => Yumrepo[] } to require all instances of Yumrepo for  
> every Package?
It seems like this is another case for being able to specify that  
something is ''first'' (and we should probably also support a
"last").

Maybe just make ''everything'' a special value for
''before'' and
''require''?  As in, require => everything, or before =>
everything?

Then just have a special check that makes sure that there are no  
relationships that cause conflict here, pull the resources out of the  
sorted list, and stick them at the ends respectively.

Sound like a sufficient yet sensible solution?

  --
  A little government and a little luck are necessary in life, but  
only a
  fool trusts either of them.      -- P. J. O''Rourke
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On Feb 7, 2007, at 2:30 PM, David Lutterkort wrote:
>
> No. That would leave your system in a semi-installed state. It might
> make more sense to add a parameter to the package type that lets you
> indicate whether removal of a package also removes its dependencies
> (that''s what this cyclical business boils down to)
>
> For the yum provider, that would mean running ''yum erase''
instead of
> ''rpm -e''
For this kind of thing, I''d like to defer to the packaging users.

It''d almost be nice to have a designated person responsible for each  
provider, someone who knows that product well and can competently  
determine its interface with Puppet.

  --
  The Washington Bullets are changing their name.  The owners no longer
  want their team''s name to be associated with crime.  So from now on  
the
  team will be known as The Bullets.
                  -- Paul Harvey, quoting Argus Hamilton
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

In response to:

<quote_Luke_Sayeth>

It seems like this is another case for being able to specify that
something is ''first'' (and we should probably also support a
"last").

Maybe just make ''everything'' a special value for
''before'' and
''require''?  As in, require => everything, or before =>
everything?

Then just have a special check that makes sure that there are no
relationships that cause conflict here, pull the resources out of the
sorted list, and stick them at the ends respectively.

Sound like a sufficient yet sensible solution?
</quote_Luke_Sayeth>

Would it be possible to do some kind of SysV Init like system where you can
number things if you want to.  Say, default 50; 0 happens first and 100
happens last and things that have the same number can happen in any order
within that hierarchy.

Or, be able to say type A before type B as a pure type.  I haven''t
delved
into the Puppet state machine mechanics, but that should support creating a
weighted graph instead of a semi-random graph.

That said, the way Luke proposed would be easy and probably cover 80% of the
cases.

Thanks,

Trevor


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Feb 8, 2007, at 12:26 PM, Trevor Vaughan wrote:
>
> Would it be possible to do some kind of SysV Init like system where  
> you can number things if you want to.  Say, default 50; 0 happens  
> first and 100 happens last and things that have the same number can  
> happen in any order within that hierarchy.
I''m not specifically opposed to this, but Puppet currently does a  
topological sort using a dependency graph, and I think it would be  
quite difficult to integrate that with numbers.  It''s pretty easy to  
tack things onto the beginning or end of the list, as long as they  
don''t have dependencies that screw things up, but it''s a lot
harder
keeping the topo sort and messing with the middle of the graph.
> Or, be able to say type A before type B as a pure type.  I haven''t
> delved into the Puppet state machine mechanics, but that should  
> support creating a weighted graph instead of a semi-random graph.
You clearly already know as much about graphing as I do. :)

Yeah, I expect that''s possible, although I don''t specifically
know
how to do it.  I''d love help in this area.

  --
  Everything that is really great and inspiring is created by the
  individual who can labor in freedom.  -- Albert Einstein
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Let me see if I have some things right.

First, you do a topological sort and put things into a list  of some sort by
which the operations are done.

Second, you go through the list one by one and execute each action in turn.

So, if you at a step between the two that takes an additional object
attribute, priority (default 50), and do a ruby sort on that array using
that priority object as your sort metric, then they should all be in the
right order according to numerical priority.

Of course, you can override certain priorities like yumrepo and package to
be perhaps 48 and 49 respectively so that they end up before the rest.

Unfortunately, I''m just swamped with school right now, but perhaps once
that''s over I can learn Ruby and get around to it....otherwise, I hope
this
helped.

Thanks,

Trevor

On 2/8/07, Luke Kanies <luke@madstop.com> wrote:
>
> On Feb 8, 2007, at 12:26 PM, Trevor Vaughan wrote:
> >
> > Would it be possible to do some kind of SysV Init like system where
> > you can number things if you want to.  Say, default 50; 0 happens
> > first and 100 happens last and things that have the same number can
> > happen in any order within that hierarchy.
>
> I''m not specifically opposed to this, but Puppet currently does a
> topological sort using a dependency graph, and I think it would be
> quite difficult to integrate that with numbers.  It''s pretty easy
to
> tack things onto the beginning or end of the list, as long as they
> don''t have dependencies that screw things up, but it''s a
lot harder
> keeping the topo sort and messing with the middle of the graph.
>
> > Or, be able to say type A before type B as a pure type.  I
haven''t
> > delved into the Puppet state machine mechanics, but that should
> > support creating a weighted graph instead of a semi-random graph.
>
> You clearly already know as much about graphing as I do. :)
>
> Yeah, I expect that''s possible, although I don''t
specifically know
> how to do it.  I''d love help in this area.
>
>   --
>   Everything that is really great and inspiring is created by the
>   individual who can labor in freedom.  -- Albert Einstein
>   ---------------------------------------------------------------------
>   Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Feb 8, 2007, at 3:16 PM, Trevor Vaughan wrote:
> Let me see if I have some things right.
>
> First, you do a topological sort and put things into a list  of  
> some sort by which the operations are done.
>
> Second, you go through the list one by one and execute each action  
> in turn.
Basically, yep.
> So, if you at a step between the two that takes an additional  
> object attribute, priority (default 50), and do a ruby sort on that  
> array using that priority object as your sort metric, then they  
> should all be in the right order according to numerical priority.
Except that that will destroy the sorting from the topological sort,  
right?

I could see it working for otherwise-adjacent resources, or somehow  
being used for a weighted sort, I would think, but I don''t really  
know how to do either of these.
> Of course, you can override certain priorities like yumrepo and  
> package to be perhaps 48 and 49 respectively so that they end up  
> before the rest.
>
> Unfortunately, I''m just swamped with school right now, but perhaps
> once that''s over I can learn Ruby and get around to  
> it....otherwise, I hope this helped.
This is actually a very small chunk of code, all in the  
Puppet::Transaction class.  The topsort is called in prepare().  If  
we could do a weighted sort, that would just need to be modified.

I.e., if you can help me understand how it might work, I can do it.

  --
  Susskind''s Rule of Thumb:
      Don''t ask what they think. Ask what they do.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Ok, this is pure fishing since I don''t quite know what I''m
looking at
completely but...

In puppet/external/gratr/search.rb line 219 describes a weight attribute
that might do what needs to be done if mapped onto the object.

What do you think?

Thanks,

Trevor

On 2/8/07, Luke Kanies <luke@madstop.com> wrote:
>
> On Feb 8, 2007, at 3:16 PM, Trevor Vaughan wrote:
>
> > Let me see if I have some things right.
> >
> > First, you do a topological sort and put things into a list  of
> > some sort by which the operations are done.
> >
> > Second, you go through the list one by one and execute each action
> > in turn.
>
> Basically, yep.
>
> > So, if you at a step between the two that takes an additional
> > object attribute, priority (default 50), and do a ruby sort on that
> > array using that priority object as your sort metric, then they
> > should all be in the right order according to numerical priority.
>
> Except that that will destroy the sorting from the topological sort,
> right?
>
> I could see it working for otherwise-adjacent resources, or somehow
> being used for a weighted sort, I would think, but I don''t really
> know how to do either of these.
>
> > Of course, you can override certain priorities like yumrepo and
> > package to be perhaps 48 and 49 respectively so that they end up
> > before the rest.
> >
> > Unfortunately, I''m just swamped with school right now, but
perhaps
> > once that''s over I can learn Ruby and get around to
> > it....otherwise, I hope this helped.
>
> This is actually a very small chunk of code, all in the
> Puppet::Transaction class.  The topsort is called in prepare().  If
> we could do a weighted sort, that would just need to be modified.
>
> I.e., if you can help me understand how it might work, I can do it.
>
>   --
>   Susskind''s Rule of Thumb:
>       Don''t ask what they think. Ask what they do.
>   ---------------------------------------------------------------------
>   Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Feb 8, 2007, at 4:00 PM, Trevor Vaughan wrote:
> Ok, this is pure fishing since I don''t quite know what
I''m looking
> at completely but...
>
> In puppet/external/gratr/search.rb line 219 describes a weight  
> attribute that might do what needs to be done if mapped onto the  
> object.
>
> What do you think?
That only works with that specific algorithm (A*), and it''s an  
algorithm that searches for a path through a graph, which isn''t  
useful for this case.

I can probably figure out how to hack up a weighted topsort, though;  
it should just be a question of using that weight when sorting  
otherwise-equivalent resources.

  --
  I am a kind of paranoiac in reverse. I suspect people of plotting
  to make me happy.                     --J. D. Salinger
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On Thu, 2007-02-08 at 07:09 -0500, Trevor Vaughan wrote:
> That said, I would still like to see a basic ''force''
option for the
> cases where yum says that I can''t do something because
it''s part of
> the base distro (like uninstalling cups) when I know for sure that I
> can. 
Running ''yum erase cups'' should get you that, though I have no
idea how
much of your install that will take with you. I am _very_ much against
just removing packages from the middle of a dependency chain - if you do
that you are essentially running an install that is guaranteed to be
untested.
> Also, I just found out that the existance of both a yumrepo object and
> a package statement do not order correctly by default. 
That''s a bug in the yumrepo provider, really; packages that use the yum
provider should just autorequire all the yumrepo objects. I''ll have a
look at fixing that, but it''ll be a while before I''ll have
time to do
that.

David

2007/2/8, Trevor Vaughan <peiriannydd@gmail.com>:
>
> In response to:
>
> <quote_Luke_Sayeth>
>
> It seems like this is another case for being able to specify that
> something is ''first'' (and we should probably also support
a "last").
>
> Maybe just make ''everything'' a special value for
''before'' and
> ''require''?  As in, require => everything, or before
=> everything?
>
> Then just have a special check that makes sure that there are no
> relationships that cause conflict here, pull the resources out of the
> sorted list, and stick them at the ends respectively.
>
> Sound like a sufficient yet sensible solution?
> </quote_Luke_Sayeth>
>
> Would it be possible to do some kind of SysV Init like system where you
> can number things if you want to.  Say, default 50; 0 happens first and 100
> happens last and things that have the same number can happen in any order
> within that hierarchy.
>
> Or, be able to say type A before type B as a pure type.  I haven''t
delved
> into the Puppet state machine mechanics, but that should support creating a
> weighted graph instead of a semi-random graph.
>
> That said, the way Luke proposed would be easy and probably cover 80% of
> the cases.
>
>
I''m not sure this is the right approach (nor the before =>
everything
solution neither the priority stuff)... I don''t remember exactly what,
but I
seem to recall some problems related with this kind of ordering just in the
init scripts in Gentoo. Just imagine you have A, B, B before everything (so
it should go before A), and then somebody creates C before B, and C after A.

Best regards
Jose


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Cups is one of those interesting beasts with Red Hat/Fedora due to the FHS.

lpr is required by the FHS, thus cups is required.  But...it doesn''t
actually have any functional dependencies.

It''s not really a big deal, just an example of more annoying packaging
deps
for no particular reason besides the FHS.

Fun, eh?

Trevor

On 2/8/07, David Lutterkort <dlutter@redhat.com>
wrote:
>
> On Thu, 2007-02-08 at 07:09 -0500, Trevor Vaughan wrote:
> > That said, I would still like to see a basic ''force''
option for the
> > cases where yum says that I can''t do something because
it''s part of
> > the base distro (like uninstalling cups) when I know for sure that I
> > can.
>
> Running ''yum erase cups'' should get you that, though I
have no idea how
> much of your install that will take with you. I am _very_ much against
> just removing packages from the middle of a dependency chain - if you do
> that you are essentially running an install that is guaranteed to be
> untested.
>
> > Also, I just found out that the existance of both a yumrepo object and
> > a package statement do not order correctly by default.
>
> That''s a bug in the yumrepo provider, really; packages that use
the yum
> provider should just autorequire all the yumrepo objects. I''ll
have a
> look at fixing that, but it''ll be a while before I''ll
have time to do
> that.
>
> David
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Thu, 2007-02-08 at 13:26 -0500, Trevor Vaughan wrote:
> Would it be possible to do some kind of SysV Init like system where
> you can number things if you want to.  Say, default 50; 0 happens
> first and 100 happens last and things that have the same number can
> happen in any order within that hierarchy. 
I would be vary careful going down that road - SysV Init is notoriously
brittle and inflexible, not least because of the static ordering of
service starts. A dependency based system like puppet has right now is
much less brittle.

And as I said, the concrete problem of uninstalling packages with
circular dependencies should be solved by using ''yum erase'' in
the yum
provider. It''s on my todo list, though will take me a little while to
get to as I am travelling right now.

David

On Fri, 2007-02-09 at 09:06 -0500, Trevor Vaughan wrote:
> Cups is one of those interesting beasts with Red Hat/Fedora due to the
> FHS.
> 
> lpr is required by the FHS, thus cups is required.  But...it
doesn''t
> actually have any functional dependencies.
>
> It''s not really a big deal, just an example of more annoying
packaging
> deps for no particular reason besides the FHS. 
> 
> Fun, eh?
That doesn''t mean that if you know you can get away with a non-LSB
system that you can''t uninstall the package (or, even better, tweak
your
kickstart to not install it in the first place)

David

This makes sense but it still leaves the issues in regards to things like
''all yumrepos must be defined before packages can be
installed''.

Or, you can just run puppet four or five times the first time with different
tags.

Not fun, but it works.

Trevor

On 2/9/07, David Lutterkort <dlutter@redhat.com>
wrote:
>
> On Thu, 2007-02-08 at 13:26 -0500, Trevor Vaughan wrote:
> > Would it be possible to do some kind of SysV Init like system where
> > you can number things if you want to.  Say, default 50; 0 happens
> > first and 100 happens last and things that have the same number can
> > happen in any order within that hierarchy.
>
> I would be vary careful going down that road - SysV Init is notoriously
> brittle and inflexible, not least because of the static ordering of
> service starts. A dependency based system like puppet has right now is
> much less brittle.
>
> And as I said, the concrete problem of uninstalling packages with
> circular dependencies should be solved by using ''yum
erase'' in the yum
> provider. It''s on my todo list, though will take me a little while
to
> get to as I am travelling right now.
>
> David
>
>
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Trevor Vaughan <peiriannydd@gmail.com> writes:
> Cups is one of those interesting beasts with Red Hat/Fedora due to the
> FHS.
> lpr is required by the FHS, thus cups is required.
Er, huh?  Surely the FHS isn''t that dumb.  It''s just a
standard on where
to put files, not on what programs you have to have installed.
> But...it doesn''t actually have any functional dependencies.
> It''s not really a big deal, just an example of more annoying
packaging
> deps for no particular reason besides the FHS.
This is at least a very strange interpretation of the FHS.  Debian
complies with the FHS but doesn''t require that you carry useless
packages
around.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

The FHS doesn''t prescribe any particular package but Red Hat/Fedora
have
decided that traditional lpr isn''t good enough and cups is the solution
of
choice.

Trevor

On 2/9/07, Russ Allbery <rra@stanford.edu> wrote:
>
> Trevor Vaughan <peiriannydd@gmail.com> writes:
>
> > Cups is one of those interesting beasts with Red Hat/Fedora due to the
> > FHS.
>
> > lpr is required by the FHS, thus cups is required.
>
> Er, huh?  Surely the FHS isn''t that dumb.  It''s just a
standard on where
> to put files, not on what programs you have to have installed.
>
> > But...it doesn''t actually have any functional dependencies.
>
> > It''s not really a big deal, just an example of more annoying
packaging
> > deps for no particular reason besides the FHS.
>
> This is at least a very strange interpretation of the FHS.  Debian
> complies with the FHS but doesn''t require that you carry useless
packages
> around.
>
> --
> Russ Allbery (rra@stanford.edu)            
<http://www.eyrie.org/~eagle/>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Trevor Vaughan <peiriannydd@gmail.com> writes:
> The FHS doesn''t prescribe any particular package but Red
Hat/Fedora have
> decided that traditional lpr isn''t good enough and cups is the
solution
> of choice.
The FHS should not be requiring *any* printer support, period, whether it
be lpr or CUPS.  It''s a standard for where to put things *if*
they''re
installed, not a standard for what is installed.

Looking at the FHS, I don''t see any place where it would require
something
like this.

Are you *sure* that you mean the FHS, and not, say, LSB (which does have
requirements about what packages are installed)?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

*Sigh*...Of course I mean LSB!

Late night last night, sorry for the confusion in the previous posts and
thanks to Russ for correcting me.

Loud and wrong today,

Trevor

On 2/9/07, Russ Allbery <rra@stanford.edu> wrote:
>
> Trevor Vaughan <peiriannydd@gmail.com> writes:
>
> > The FHS doesn''t prescribe any particular package but Red
Hat/Fedora have
> > decided that traditional lpr isn''t good enough and cups is
the solution
> > of choice.
>
> The FHS should not be requiring *any* printer support, period, whether it
> be lpr or CUPS.  It''s a standard for where to put things *if*
they''re
> installed, not a standard for what is installed.
>
> Looking at the FHS, I don''t see any place where it would require
something
> like this.
>
> Are you *sure* that you mean the FHS, and not, say, LSB (which does have
> requirements about what packages are installed)?
>
> --
> Russ Allbery (rra@stanford.edu)            
<http://www.eyrie.org/~eagle/>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users