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

Splitting libcatalyst-modules(-extra)-perl

-=| intrigeri, 12.05.2014 16:34:42 +0200 |=-
> Damyan Ivanov wrote (12 May 2014 10:06:45 GMT) :
> > So, what do others think about bundles?
> We should split them, to ease maintenance and deprecation.
> FTR, I committed to do it for the Catalyst ones at some recent DebConf
> (12, maybe?), failed, and then lost interest. Sorry.

Fully understood. Let's see how far will I get :)

> > I know at some point there was a concern that FTP masters don't 
> > like too small packages. This may no longer be true, and even if 
> > it is, libcatalyst-modules-perl for sure has quite some modules 
> > that are not "small" by any measures:
> I'm not sure these modules are substantially smaller than many other
> distributions we package, so IMO it's worth a try.


-=| gregor herrmann, 12.05.2014 16:34:52 +0200 |=-
> On Mon, 12 May 2014 13:06:45 +0300, Damyan Ivanov wrote:
> > I'd like to survey the opinion of the team about CPAN modules packaged 
> > as bundles.
> Yay, one of our recurring favourite discussion items :)

Somehow I forgot about the past discussions. Sorry for not doing my

> > First I tried to make their maintenance easier, with main goal 
> > making the upgrades more accountable by having modules' sources 
> > tracked expanded in the packaging Git. This worked fine with 
> > libcatalyst-modules-perl. You may want to compare that to 
> > libcatalyst-modules-extra-perl, which still uses tarballs instead 
> > of expanded sources.
> The looks indeed very nice, compared to the old status. Thanks!


> > All in all, after working on libcatalyst-modules-perl, I wish it was 
> > not a bundle. Improving the bundle management makes things easier, but 
> > still not as much as the ordinary non-bundled packages.
> Ack.
> > So what do others think? To bundle or to split?
> Not digging out all previous discussions but: the current (?) status
> seems to be:
> https://wiki.debian.org/Teams/DebianPerlGroup/OpenTasks
> "bundle packages: just do it, and see what happens (notes:
> pkg-components, ftp-master clarification)"
> where 'just do it' it means: split them up, and 'ftp-master
> clarification' is a link to https://bugs.debian.org/606411

Seems good enough. "Size is not important, usability is".

So I'll go on with the split.

My plan is as follows.

Start with bundle/01/*, and:

 * create separate package for each dist there
 * make them break/replace libcatalyst-modules-perl (<< $X)
 * make libcatalyst-modules-perl (version $X) build-depend on the 
   separate packages
 * make libcatalyst-modules-perl (v. $X) Depend on the separate 
   packages (or, in case the module is deprecated upstream, Recommend)
 * upload libcatalyst-modules-perl version $X when the separate 
   packages clear NEW

Repeat the above for bundle/* in numerical order, several packages at 
a time. libcatalyst-modules-perl has 32 dists in it. 
libcatalyst-modules-extra-perl has only 5.

After Jessie is out, drop deprecated plugins' packages, and drop the 
Recommends. Hopefully the build-dependency chain is not circular.

If you see any flaws in the above, now is the time to use your 
cluebats :)

-- dam

Attachment: signature.asc
Description: Digital signature

Reply to: