On Tue, Feb 14, 2017 at 10:11:09PM +0000, Emil Velikov wrote: > Thanks for having a look Alan. > > On 14 February 2017 at 16:31, Alan Coopersmith > <[email protected]> wrote: > > This one seems useful/important: > >> + build lib libXpresent > > > > Are you using the github version for this since it moved off fd.o? > >> + build lib libxkbcommon > > > > I don't know what this is: > >> + build lib libXrandrUtils > > > > This was a student project that I don't know if it ever got finished or > > adopted: > >> + build lib libxcwm > > > > The rest are deprecated/obsolete/unused: > > Rather than scattering, I'll try to sum it up here: > > Patches 4-9 are sort of RFC, at least for the time being. > IMHO it makes sense to have all the repos listed since amongst others > it makes it easy to track/sync the list via the diff command provided. > > Now to the moved/foo/bar repos. One idea boils down to having a checked-in > file. > - moved - "moved-to" -> git clone ... `cat $ROOT/$MODULE/moved-to` > and act accordingly > - no longer maintained - "unmaintained" can be used to > a) track if configure.ac has been updated (returns unique error code) > b) warn early when explicitly requesting to configure/build the module, other > - odd repos - xorg/xserver-test anyone, xproto, other - nuke them ;-)
What's the end goal of this though? Having configure nuke out seems like the most sensible solution for any repository that has surpassed its useful life. And *not* having it in the build.sh script is likely better to avoid erroneous clones than having an external file that tracks this. We do have a MAINTAINERS file somewhere, in theory that could already be used to list deprecated repositories. > "Fixing" things roughly like above will take some time, but I wouldn't > mind helping out every now and then. This is something where I think we'd have to have everything in place in one go. Because if we merge the patches 4-9 but then not update the rest for another year, we'll have a year's worth of people checking out repositories that they don't need. Or worse, repositories, that break the build.sh run. Cheers, Peter _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
