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

Re: Challenges around Perl 5.20



On Mon, 02 Jun 2014 17:38:05 +0200, Jonas Smedegaard wrote:

> Quoting Dominique Dumont (2014-06-02 15:59:48)
> > On Sunday 01 June 2014 19:10:48 gregor herrmann wrote:
> >> This still leaves the questions if
> >> - cme can create something like this, and
> Right, I don't know if cme is limited to atomic statements.
> > yes. That does not mean it's a good idea
> Uhm, what are you saying?  Do you imply that it means the opposite?

I think dod is saying that it would be possible but that he doesn't
consider it a good idea.
 
> > It is much simpler to handle for us and dpkg resolver. Jonas' trick 
> > will probably trigger questions from perl packagers (present and 
> > futures)
> Could you elaborate on which kinds of questions if would trigger to 
> express the complex dependency as I propose?

From my own packaging and package-updating experience, and especially
from reviewing packages prepared by people less experienced than e.g.
you, I know that getting these alternative dependencies right is not
trivial. Adding more complexity by those "double alternatives" will
IMO lead to more confusion and hence to more time spent with package
preparation and reviews and explaining the constructs in
changelogs/mails/IRC over and over again.

I'm a bit skeptical that that's worth the effort.
 
> Even if not possible for cme to automate what I propose, some (including 
> me) might still express it by hand (e.g. to ease backporting), and it 
> would be quite relevant to understand what might backfire in that 
> approach.

It might not help to attract more people to help out with your
packages but besides that it should be fine :)
 
> > The only drawback I see: some systems may needlessly install modules 
> > when installing backported perl packages.
> > Is that a big deal ?
> Becomes bigger if the module needlessly pulled in also need backporting.  
> If then the needlessly pulled in and backporting-requiring package has
> sloppy dependencies on e.g. a newer than really needed debhelper or 
> Moose, it becomes even bigger...

True ...
 
Cheers,
gregor


-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Alannah Myles

Attachment: signature.asc
Description: Digital Signature


Reply to: