Re: Adding provides: for Drupal packages
[sorry for resending this, due to a silly restriction of lists.d.o]
Hi, Gunnar
On Tuesday 14 September 2010 16:39:35 Gunnar Wolf wrote:
> I see with great joy that you are packaging Drupal modules following
> the naming scheme I came up with, and presumably using my
> dh-make-drupal tool ;-)
Yes. Every time i develop something new i try to stick to the Debian stable
and when it's not possible i'm starting to package stuff for Debian as a part
of the project. dh-make-drupal is an incredibly useful helper!
#1
> I have not yet uploaded my latest changes to Debian (and will probably
> revert them if I find a better alternative), but you can fetch them at
> http://github.com/gwolf/dh-make-drupal ; what I added since 0.7 is the
> generation of a Provides: line for all provided submodules (that is,
> for every *.info file inside the module). I am still uncertain whether
> this is a good move, as it is not policy-clean (i.e. I'm just
> inventing virtual package names), but it works at least for my locally
> built packages.
Indeed, this is against Policy which considers Provides as a tool to group
real packages by functionality, not to reveal internals (as in RPM). In
particular, when versionned dependency is used, no virtual packages would be
taken into account. This is why i don't like this approach.
#2
> What I was thinking about doing is to find where in
> Drupal's site are such provides:-equivalents spelt out (as I'm almost
> sure a module can point out to what module it requires!)
I'm not so sure, i'm afraid. Since there's no automatic way to download
modules (in D6, at least; what about D7?), they just don't need this info.
#3
> Anyway - What I want to do is to either find that information or set
> up a, say, drupalpkg.debian.net service with this data so that built
> modules can properly say "Depends: drupal6-mod-cck" when
> something.info includes a dependency on "content".
I feel, such an external service can end up by an administrative hell
considering you will have a huge number of dimensions in there.
> Any ideas?
Well, the pretty straightforward idea is to propose an additional field
for .info (to say, "provides"), which will reveal internals of the module.
AFAIS it could be filled automatically by Drupal's packaging tools if such
tools exist. Or you can put your own data there manually instead of #3. In
result, we will have #2 and wont break the Policy by doing #1.
What do you think?
Reply to: