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

Tue Jul 7 14:19:21 UTC 2009

2009/7/5 Micah Anderson <micah at riseup.net>:
>
> 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.

For me it's not so much protecting against things as it is taking
advantage of a package management system.

If you install facter or puppet, you're going to also pull in all the
dependencies. Ruby, relevant gems, etc etc.

If you use an env shebang, you're no longer sure whether the ruby
runtime you're invoking actually provides all the required
dependencies.

Looking at the Debian Ruby Policy:

http://pkg-ruby.alioth.debian.org/ruby-policy.html/ch-ruby.html#s-interpreter

and the Debian Python Policy:

http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-interpreter_loc

we see that the Ruby one isn't worded anywhere near as strongly as the
Python one, yet I believe exactly the same arguments apply.

"If a maintainer would like to provide the user with the possibility
to override the Debian Python interpreter, he may want to use
/usr/bin/env python or /usr/bin/env pythonX.Y. However this is not
advisable as it bypasses Debian's dependency checking and makes the
package vulnerable to incomplete local installations of python. "

I don't think it's advisable, and if it comes down to a vote amongst
us, my vote is in favor of an explicit, non-env shebang.

>
>> > 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQIcBAEBCgAGBQJKUQP6AAoJEIy/mjIoYaeQ3i4P/2BNxsgWx6TZg7LH6fTPoS1B
> DziBSeoXKUhjIKKlEMK7VW2jwalgVaUY9NL85v3o78egLHitcHqxWmNrJGvAFXxm
> h9nU4Yp1w9/oJSFAQGNnw0xoYWqPRQ99NVa1604HwNNE+kOtHLIIGQerAHSysGNF
> bVu+AaZ+tHiHuaiHSE/JEI6/7PGD6koge3HkIucIxcs0BkUBc1LgLr3Lc8kLM+ku
> 1O0SDQromhQHMHViNfDdNgaoyf36hGlqKtvIU0i+IK2rczudXIHsT5u9/syCYQgE
> eGFhlqVD655NJKD8P07hMTbC4feFHyL0Q49ThDuw1+MCNBKela+dhsckcI1+IJI1
> YdnidBk9Wgo3ZfBqXGs9pRTMhxv9O3X5zhNo+xSB+Me1b5/6WdyGQ1bv9Vx/ukYS
> 2Y7A+phx/FkyMHUEhV9OMO8Hsk1qD+cQSzgSsy19PrBVHqjXGlsxEa3fGy+zM6dk
> KADHuP7s+i2zET5rWvnb+iTpoUpoaOHAdFIl/5HQ9zFQ/V1lfK4UIj47Hso6nR7j
> CGWkROsVhGo75sO8bhiDzZNHyIzv2Oggev9SxJgbFmM+eWxsqrhd90flTmGkrN8j
> MI8SFrzHxKZq4c7zb1/99EzDCdBzO1D864DWCemgwfEmvA+ctKlCbtBJgfPaBHmY
> yQJieZp/SFnMYTg/e5pv
> =n8T8
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Pkg-puppet-devel mailing list
> Pkg-puppet-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-puppet-devel
>
>