[Pkg-puppet-devel] puppet-agent_7.16.0-1_amd64.changes ACCEPTED into experimental, experimental

Thomas Goirand zigo at debian.org
Tue May 17 18:02:53 BST 2022


Hi Antoine,

Thanks for voicing your opinion.

On 5/16/22 17:28, Antoine Beaupré wrote:
> On 2022-05-16 15:23:40, Thomas Goirand wrote:
>> There's on consequence switching the source package name, and never the
>> need to ask anyone about it, so I honestly don't care about this.
> 
> What do you mean by "on consequence"? Did you mean "no consequence"?

Yes, sorry for the typo.

> It seems to me it would actually be a good thing to review those
> dependencies, since we *are* splitting the server and agent part. All
> the puppet-module-* packages, for example, probably do not *need* to
> Depend on the puppet-agent package, that might just be a "Recommends",
> right?

Well, I first had these modules depending on puppet-common, as I copied 
it from other module packaging, and I was told to make my packages 
depend on puppet instead. I could somehow accept to change things again, 
but IMO, we must not take it lightly, and define a clear, well thought 
policy for these packages.

On my last message, I was probably just a bit grumpy because I'm 
thinking in advance that it's going to take me at least 2 full days of 
work to fix all of these dependencies...

> I otherwise happen to agree with lavamind's change: I think puppet-agent
> is a better name for the binary package. It states clearly that it's
> *just* the agent (whereas the "puppet" package before was possibly
> shipping more, and had intermingled deps with the server). When we did
> the previous switch, wasn't it exactly because the codebase was shared,
> something that was changed upstream?

I'm not sure, I just did what I was told without thinking much... Maybe 
I should reconnect my brain this time? :)

Now, for the naming, if I want to be fully honest and ignore my 
laziness, what we should do is use the upstream naming as much as 
possible. I just checked, and they do use "puppet-agent" for the agent, 
and "puppetserver" (one word, no dash...) for the server.

To be noted: the puppetserver package is >= 70 MB. Knowing what we know 
about what's inside (ie: super dirty and many stuff embedded) it's not 
surprising. IMO, we should attempt packaging jruby with the ruby 
interpreter embedded in the package, because that's already much nicer 
than what puppet upstream provides.

Thanks for baring with me. :)

Cheers,

Thomas Goirand (zigo)



More information about the Pkg-puppet-devel mailing list