2014-07-19 20:16 GMT+02:00 Zachary Storer <zacts.3.14...@gmail.com>: > 1) If we decide to automate upgrading all of the perl/ slackbuilds to > use the latest version, how should we make sure it doesn't break other > slackbuilds that rely on that perl module? > > 2) If we decide to automate upgrading all of the perl/ slackbuilds, > should we have just a single maintainer for _all_ of the perl/ > slackbuilds, or should we continue with having a different maintainer > for each perl slackbuild module?
these two don't seem very reasonable to me: we have no guarantee at all that 1) works painlessly and about 2) we cannot have a single mantainer for all the perl stuff (he could become crazy -also there will be problems on new perl submissions, etc., etc.). maintainig perl modules through automated updates will lead to major breakages, IMHO. > 3) #perl on freenode recommended that we use www.cpan.org for the > download link, if we decide to do this rather than using metacpan for > the download link, we will have to upgrade all perl/ slackbuilds to > their latest version, or we will have dead links. So, would you like > to use www.cpan.org for the download link, or would you rather use > metacpan for the download link until we make a decision on for my > question #2? I would say to use metacpan for homepages and download links, but before giving a personal opinion I would like to read some statements about the cpan situation from some perl source... Matteo _______________________________________________ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/