-=| 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. Ack. -=| 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 homework. > > 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! 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