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

[Micah Anderson]

* Andrew Pollock <me at andrew.net.au> [2009-06-30 15:45-0400]:
> On Tue, Jun 30, 2009 at 04:53:37PM +0000, Micah Anderson wrote:
> > The following commit has been merged in the master branch:
> > commit 9b25e4ae9cea6dfce1db3f253d461c01533720c7
> > Author: Micah Anderson <micah at riseup.net>
> > Date:   Tue Jun 30 12:36:51 2009 -0400
> > 
> >     Now that upstream has done quite a bit of work to get facter to work
> >     with ruby 1.9 we need to make the Debian package work with ruby1.9.
> >     
> >     This came about because there was a lintian problem:
> >     
> >     E: facter: ruby-script-but-no-ruby-dep ./usr/bin/facter
> >     
> >     That happened because the install.rb, provided by facter, munges the
> >     perfectly fine shebang in bin/facter (#!/usr/bin/env ruby) into the
> >     ruby1.8 specific one (#!/usr/bin/ruby1.8) just because my
> >     /usr/bin/ruby is a symlink to /usr/bin/ruby1.8.

[snip:  Some details from the commit log (23 lines)]

> So a big fat +1 for a nice detailed commit message, but a big fat -1 for the
> resulting change. 

I would also say a big fat -1 for switching to CDBS, something I am not
really a fan of and something that isn't particularly nice to do without
talking with people first (maybe thats a big fat -2?).

> Perhaps if we'd been as verbose in our commit messages, this wouldn't
> have happened.

True... true... I saw the commit message that was there about the switch
to upstream's install.rb but didn't think it was done for anything more
than what was detailed in the changelog:

  * Use upstream install.rb script to build rather than copying manually

Seems innocent enough, additionally, using upstream's build system is a
good thing (the one thing remaining from the work I did this morning was
to report a bug upstream to request that they switch to setup.rb so
there could be more flexibility).

> We went to great pains to switch over to using install.rb expressly because
> we wanted to get away from from having "#!/usr/bin/env ruby" as the shebang
> line, because we were seeing machines where users had messed around with
> their ruby runtime and Facter (and Puppet) ended up running with something
> out of /usr/local/bin instead of the system-provided one, and everything
> broke spectacularly.

Ok, so we need to figure out how to handle this. One advantage of using
setup.rb is that we have flexibility with the shebang line now:

--shebang=(all|ruby|never)

    Shenbang line (#!) rewriting mode.

    all: replace all shebang lines.
    ruby: replace shebang lines which invokes ruby.
    never: never rewrite shebang.

So the situation you describe can be avoided, however I'm not sure how
we can reconcile both issues at the same time.

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 :)

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?

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

This is a good first step in that direction. Perhaps one other step we
could make would be to take a step back before uploading and ask the
list before pulling the trigger? 

micah

ps - I'm on IRC frequently, and welcome conversation there (either in
the upstream #puppet channel, in #debian-ruby, #debian-devel, or
whatever) too.

-------------- 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/20090630/83f2ba24/attachment-0001.pgp>