Hey Pierre,
> I'm so sorry for the poor wording, Ricardo, it was uncalled for. (Wrote in a > haste.) What I meant is that it does not solve the current issue of "what > file > belongs to what package." No worries :) > It's not just the importer but our current approach to TeXlive that we've got > to > work out. I agree. It’s always been messy and currently it’s pretty frustrating to package or update TeXlive packages. What I find most troubling is that sources are littered across the SVN repository. Sometimes we’ve got simple .ins and .dtx files, but very often we have a stray .sty or .tex file in some seemingly arbitary directory and one needs to manually take care of adding these extra source files to the native-inputs. This could be improved even before a full overhaul of our TeXlive handling: add a convenience procedure that takes a list of file names in the repository and collects them via SVN as the source tree. Beats having to add extra build phases and the like. >> : I'm more and more convinced that rewriting the texlive-build-system >> centered >> : around texlive.tlpdb would work and is the right approach. >> >> Could you please outline what this would mean? > > Sure: if you look at the file, you'll see it's a textual database of all > packages with their respective file. A possible solution that we could > implement either as a build-system or an importer: lookup the package in the > tlpdb > (e.g. mflogo) and package all the corresponding file from the svn repo. > Sounds > simple enough. What do you think? I don’t see this file in the texlive SVN repository. Where is it hosted? So, it’s a map of packages to file names? That would probably simplify the importer. I don’t think it would help with the build system. Am I missing something? -- Ricardo
