2015-03-27 16:58 GMT-03:00 Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx>: > On Fri, Mar 27, 2015 at 08:28:21PM +0100, drago01 wrote: >> Actually "machine generated" isn't per se bad ... it saves a lot of >> effort and should be done more (for other packages too where >> possible). >> Why waste man power for something that can be automated? >> >> As for tex ... we could have a srpm for each one (machine generated >> there is no reason it has to be one srpm) would also mean that only >> the packages where something changes end up getting updated. > > Right, as I understand it, the gigantic single SRPM is to avoid the > normal requirement that each individual package have its own manual > review. For thousands of packages, that's quite a burden. I maintained a slowly evolving approach in Mandriva for some years, (but now it is quickly approaching one year I left Mandriva...), see the main script at https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/tlpobj2spec.pl It uses the texlive perl modules to do most of the work, and only does some filtering on contents, choosing %doc (what texlive calls doc and source), extracting dependencies or license information, %post scripts, etc. The script even handles when I messed something, or, quite common problem of upstream downgrading a version, or switching to/from version to date-version format. Another important script is https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/checkupdates.pl it assumes it is called from a top directory where there is a full checkout of all texlive packages, and, then, it relies on a specific spec header format, to tell what packages can be updated. Note that sometimes the package database and the mirrors may not agree, so, some manual intervention may be required, e.g. hardcoding to use a fast mirror, or running again to choose another mirror that agrees with the package database. I even adapted the texlive package manager to use the system package management, e.g. see official tlmgr screenshots at https://www.tug.org/texlive/doc/texlive-en/texlive-en.html#tlmgr and the adapted version to use urpmi https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/tlmgr > But the workaround, while not violating any specific guidelines, > doesn't _really_ have any more careful individual review of each of its > parts — it's not a gain. And it has negative side-effects. > > If FPC would be open to bulk-approving machine-generated individual > spec files (given, say, they're provably all following the template, > which would be reviewed), and rel-eng has some way of bulk-adding the > necessary branches and builds, that really seems like a step forward to > me. It is quite a lot of work, so, it would be better to have a SIG and not let only one person handle all packages. Once a setup like the one I used is done, it is required around 2 hours per week to keep in sync with upstream TeXLive. Assuming one can can fast create (or do a really quick review, thus a SIG) 3-10 packages per week (sometimes it will go a lot of time without new packages). Frequently packages are deprecated (no texlive package requires them), and sometime later reenabled. > Am I missing something? > > > > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader Thanks, Paulo -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
