[Pkg-puppet-devel] [SCM] Packaging of Facter for debian branch, master, updated. debian/1.5.6-1-3-gf695058

Sun Jul 5 19:50:19 UTC 2009

Sorry for the slow reply, us seppos had beer to drink.

* Andrew Pollock <apollock at debian.org> [2009-07-01 00:38-0400]:
> On Tue, Jun 30, 2009 at 05:00:18PM -0400, Micah Anderson wrote:

[el snip (14 lines)]

> > Part of me thinks that if individual users in your environment mess up
> > their ruby runtime, that is on them, and solving it by hard-coding the
> > package so all debian users must use a specific ruby version because
> > some of your users can't keep their grubby little hands off of the
> > system doesn't seem like the right way to solve your problem as any time
> > you find yourself solving a social problem with a technical one, then
> > its time to rethink things :)
> 
> Heh. If only. 
> 
> I also have a few issues with using #!/usr/bin/env in general, be it Ruby or
> Python. We really want to avoid situations where the user having root on
> their desktop manages to break Puppet before it has a chance to rectify
> things.

I don't really follow this logic because a user having root can break
all kinds of stuff that you can't possibly protect against in the
package, and just arbitrarily protecting against this one thing seems
odd. 

> > However, maybe there is some middle-ground. Perhaps by having the
> > shebang use /usr/bin/ruby (which is going to be a symlink to the
> > preferred version of ruby on the system), instead of #!/usr/bin/env ruby 
> > 
> > Would that work?
> 
> Well, yeah, unless someone dicks with the /usr/bin/ruby symlink. An ignorant
> user (at least at our site) is more likely to just mess with the filesystem
> than they are to uninstall a package.

Ok, yeah... someone can dick with the /usr/bin/ruby symlink... but if
the binary is pointing to /usr/bin/ruby1.8 what is to stop someone who
is prone to dicking around from dicking around with /usr/bin/ruby1.8?

I'm not really convinced that the right way to stop people from dicking
around is to try and protect against it through a process of dicking
with the package (well, unless the package change you want to make is
one that will take root away from them). Especially if that means
limiting the functionality of the package in the process. 

There are really a lot of things that users can do that can't be stopped
until you take away their powers and you aren't going to stop that by
changing the shebang on facter.

> What problem are you trying to solve by allowing ruby1.8 or ruby1.9,
> anyway?

First of all facter has had significant work done on it to work with
both, because people requested that it work with ruby1.9. Locking the
Debian folks into ruby1.8, when work has been done to make it work with
1.9, seems like a mistake.

Secondly, if the shebang specifies ruby1.8, then lintian throws an error
due to the dependencies that are specified in the debian/control on a
generalized ruby. Either the shebang has to be neutral in the ruby
version, or the debian/control has to be specific and match the ruby
version shebang. 

> I'd be inclined to pick one or the other and stick with it. I'd suggest
> ruby1.8 until such time that Puppet itself will work with ruby1.9 and just
> transition over. There's no problem with installing ruby1.8 and ruby1.9 at
> the same time is there? It's not like having Facter installed locks you into
> having only Ruby 1.8 installed is there?
> 

Sure we can lock people into ruby1.8, but I don't see why we would do
that, when facter can be used with ruby1.9, and not everyone who uses
facter is using puppet. I do believe that the majority of people do use
puppet who use facter, but I actually do know someone who is developing
a machine inventory tool, using facter, and he isn't bothering writing
it with anything but the latest, which means ruby1.9, and rails2.3. He
doesn't need puppet for this at all.

He might be an outlier special case, but the fact that people were
requesting facter work with ruby1.9 upstream, and they did the work to
make it work with 1.9 makes me wonder how many other people are out
there who actually do use facter without puppet. 

> My understanding is that Puppet only works with ruby1.8 at the moment, so if
> you allow Facter to run by hand with ruby1.9, but be loaded into a ruby1.8
> runtime when loaded by Puppet, won't this leave things open to inconsistent
> behaviour between running it interactively (with say ruby1.8) and running
> internally to Puppet (with ruby1.8)?

That is correct that Puppet only works with ruby1.8 (although upstream
is working on changing that), but I don't think there would be any
inconsistency in the situation that you detail. When you run facter with
ruby1.9, you get the exact same results as you do with 1.8, if you do
not upstream considers that a bug and would like to know about it. For
fun, I decided to try it by changing my facter shebang to specifically
use ruby1.9, and ran a few puppet runs in my development setup with
different recipes and there was nothing different that I could see.

If you feel strongly about this, I don't particularly mind if you put
things back and we just wait until someone complains that facter should
work with ruby1.9. Its too bad I spent the time on doing that, but thats
my own fault as I should have been doing something else anyways ;)

> > > I'd like to move to a development model where we're not all working in
> > > isolation commiting changes, but send patches to the list, and reach some
> > > sort of agreement or at the very least obtain some peer review/feedback
> > > before submitting. I'm not exactly sure how to accomplish this yet though.
> > 
> > Absolutely! I'm open to discussing and figuring out the best way to deal
> > with both of these issues. I've been kind of used to being on a team of
> > 1 for a while, and when you guys blew in and started pushing changes and
> > uploading packages without any discussion, I was not hurt in the
> > least. In fact I was relieved that someone else was doing some work so
> > I welcomed it! :) Alas, when you are working with others, sometimes
> > there are competing priorities and goals and so in the end you simply
> > must communicate. 
> 
> Well we pretty much blew in because there'd been no evidence of activity for
> some time prior. Had we known you were still doing stuff, we'd have been
> more communicative from the outset, so sorry about that.

My last commit to the repository was when 0.24.7 came out, which I
uploaded to experimental in the end of January because we were in freeze
mode. I had been responding to bugs since then... and 0.24.8 didn't come
out until March 23rd. You updated the repository April 8th (thats about
2 weeks after the release). While it is true that I had not made any
commits to the repository since the 0.24.7 upload to experimental, I
don't know if its correct to say that there had not been any evidence of
activity for some time prior. Its true that I had not had any time to
work on the 0.24.8 release, and it didn't seem like others on the team
were either, but I was still doing stuff. In any case, I don't really
hold it against you for not being more communicative, in fact, as I said
before, that was a particularly busy time for me, so I welcomed the
fresh blood. ;D

> > ps - I'm on IRC frequently, and welcome conversation there (either in
> > the upstream #puppet channel, in #debian-ruby, #debian-devel, or
> > whatever) too.
>  
> Yeah I idle in #debian-devel, but I don't pay close attention to it during
> the day, so I may not be enormously responsive. I'll see if I can make
> screen yell at me more obviously when there's activity in the window with
> irssi in it.
> 
> Perhaps we should organise a time to have a meeting on IRC and just throw
> some ideas around?

I've got a busy week and a half while I try and wrap things up before
heading to debconf, but would be happy to do so at some time either
during debconf, or after. Don't suppose any of you will be attending?

micah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-puppet-devel/attachments/20090705/4b3c3ade/attachment.pgp>