Hi Carsten,
> I'd say there is a gap which is difficult to handle in the end by only
> pointing and strictly using our more technically packaging policy in
> contrary to make the system much as possible user friendly. But o.k., I
> see your point and will respect the decision of the package maintainers.
Firstly, I totally understand this sentiment. Whilst the close
adherence to rules across a large distribution is a net welfare for
all manner of reasons I won't belabour here, it would be a cliche
to remark that there will always be scenarios where they should not
apply. Indeed, I am sure you could fill a handsome book with famous
quotes to this effect.
> > This is all to say that given that your custom patchy2 package calls
> > collectstatic during its own package configuration stage, would it not
> > make more sense to specify libjs-query as a Depends on your package
> > instead?
>
> Our application has no dependency on libjs-jquery so adding a direct
> dependency to this package wouldn't be the correct thing to me.
However, I don't believe this statement is entirely accurate. Your
application calls "collectstatic" during it's postinst script in order
to collate all of the assets for a kind of "web runtime", so in a
certain sense then, your package *does* have a dependency on
libjs-jquery that none of the Django-related packages in Debian has --
at the very least, none of them call "collectstatic". It us thus your
package thus warrants the Depends-level relation, not any of the
others. (Or alternatively, as you write, through your configuration
management system.) I would gladly concede that this is a subjective
judgement coached in technical language.
Anyway, thanks for your reply and for closing the bug. And, circling
back to my remarks above about not being overly wedded to rules, I am
very happy to re-explore this in the future if it comes up repeatedly
for others.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org 🍥 chris-lamb.co.uk
`-
