tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Cyclic dependency, please fix

 >> According to the documentation above {} braces should be expanded to
 >>     perl:../../devel/completely-different-pkg
 >>     completely-different-pkg:../../devel/completely-different-pkg

> I hope I can explain from my simple point of view:
> Module::Build is a core module of perl-5.10, so depending on perl>=5.10
> would be enough. To give those developers a hint which want to use a
> bug fixed or feature enhanced version, the second dependency is added.
> Maybe it's a dirty trick (I do not understand enough to have a real
> opinion), but it should work.

Maybe I missed something important but all this looks like
something really strange is happining here.

As a 3-rd party software developer I'm really confused.

I understand the above logic but
1) According to the documentation
       In addition, csh(1) style {,} alter- nates have been implemented.
   Nothing more about aboit {aaa,bbb}.
   csh(1) syntax means that '{b,c}d' should be expanded to 'bd cd',
   not to 'bd cd d' and not to 'bd OR cd OR d'.

   pkgsrc guide section 19.1.6 doesn't describe {} semantic at all
   refering reader to pkg_info(1).

   So, curly braces inside DEPENDS/BUILD_DEPENDS are completely

2) Dependencies listed in DEPENDS and BUILD_DEPENDS consist of two
   parts, PKGBASE/PKGNAME and path to category/package (PKGPATH).

   Following logic you described and description in pkg_info(1)
   pkg{A,B}:../../category/pkg should mean something like

      pkgA:../../category/pkg OR pkgB:../../category/pkg

   But this is not the case. It is expanded EITHER to
      pkgA:../../category/pkg OR pkgB
   or to
      pkgA OR pkgB:../../category/pkg
   or to
      pkgA../../category/pkg OR pkgB:../../category/pkg

     DEPENDS=php5-mysql{,i}>=4.3.3:../../databases/php-mysql ...

     Here we have pkgA:../../category/pkg OR pkgB case.


     Here we have pkgA OR pkgB:../../category/pkg case.

   A) {,} are irregular. The ../../PKGPATH part doesn't mean anything

   B) Because ../../PKGPATH part is broken why it is needed then?

   C) Suppose we completely ignore ../../PKGPATH.
      When we can get an information about where our dependencies come from? 

      Given an information about ALL packages in a tree
      (pkg_src_summary) in my distbb I can assign "perl" to
      "lang/perl5". No problem. But how pbulk and original BBF work then?
      How pkg_rolling-replace can resolve package's dependencies?
      AFAIU pkg_rr definitely doesn't analyse entire pkgsrc tree.

3) Is this a new feature? How long ago it appeared?
4) See example in 2). php5-mysqli is not provided at all.
5) For building correct dependencies in my distbb, should I completely
   ignore the A part in xxx{A,B}yyy constructs? If yes, then again where
   can I get ../../correct/pkgpath?

Best regards, Aleksey Cheusov.

Home | Main Index | Thread Index | Old Index