[PATCH util-modular 5/9] build.sh: add the remaining xorg lib(s)

Mon Feb 27 23:40:55 UTC 2017

On 27 February 2017 at 21:54, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> On Mon, Feb 27, 2017 at 12:09:38PM +0000, Emil Velikov wrote:
>> On 27 February 2017 at 02:10, Peter Hutterer <peter.hutterer at who-t.net> wrote:
>> > 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
>> >> <alan.coopersmith at oracle.com> 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.
>> >
>> Having the extra checkout is negligible comparing to:
>>  - we can diff (see the command in patch 4) the existing tree against
>> the current contents
>
> what do we need this for? I'm working on the assumption here that if we have
> a new and well-maintained repository, then things like build.sh updates
> should be handled by the maintainers anyway, so the diff would only provide
> us with information about dead repositories.
>
Saying this made me look at the build.sh additions and first official
release of the respective projects:
 - xf86-video-amdgpu, added to build.sh 01/2017, v1.0.0 - 11/2015
 - libinput - 08/2016, v1.0.0 08/2015
 - xf86-input-libinput - 08/2016, v0.1.0 06/2014

This brings two things to mind:
 a) people may not know/remember to update build.sh
 b) why bother remembering when one can do it [semi] automatically, in
the first place ;-)

>>  - we can automatically redirect moved repos (git clone `cat MOVED`)
>
> that is a feature i can see to be useful, but the same can be achieved in
> configure.ac, or, if you want to go to more of an extreme: git rm everything
> in the repo and only leave a README.txt with the moved project url. That's
> sure to get everyone's attention :)
>
Parsing through configure.ac/README.txt might be a bit iffy, but sure
it can work.
I'm leaning towards the latter - nuke everything but a simple README.

>>  - we can do a sanity check (that configure bails out) for deprecated repos
>
> from my experience, out-of-band checks like this just increase the
> maintenance effort with very little benefit. for example, most of the input
> drivers have been deprecated for years, checking that they still bail out
> seems superfluous.
>
If they've been unchanged for years then there will be little-to-no
maintenance effort, right ?
On the other hand:
 - if/when(?) that changes, say someone snuck behind your back and
starts maintaining xf86-input-digitaledge, it will be flagged
 - there's multiple semi-broken packages which would appreciate the
configure.ac AC_MSG_ERROR 'fix'.
Having a complete list in build.sh will point them out ;-)

>>  - the above two can be synced with a third party file (MAINTAINERS?)
>>  - but in general relying solely on MAINTAINERS (or anything that's
>> outside of the respective repo) will lead end up horrilbly out of date
>
> I'm going to argue that the same is true here, given the number of issues
> you already found with build.sh because it's barely maintained :)
>
True - cross-referencing stuff should make it easier to find. In
theory at least.

>> > We do have a MAINTAINERS file somewhere, in theory that could already be
>> > used to list deprecated repositories.
>> >
>> The MAINTAINERS is one such example.
>>
>> Actually skimming through the file we can even feed/cross reference
>> the information between it and the git config of the repos.
>> Something like -> git config  --get sendemail.cc $MAINTAINER
>
> on the subject of people being on my lawn, I like the current convention
> where I'm not CC'd on every patch automatically. once that would just
> increase my filtering needs and likely lead to more patches being missed
> than now. but that's my personal view here.
>
Ack, fair enough - was just an idea.

Generally it would be nice to have a reference to the maintainer
within the repo. The easy way to sync any reference(s) [be that with
xorg-docs or other] to that person is a big plus IMHO.

>> >> "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.
>> >
>> Fully agree - we cannot merge 4-9 as-is. I'm mostly looking for a
>> confirmation that I'm not completely loosing it and the (above) plan
>> sounds reasonable.
>
> tbh, to me it sounds like "there's all these cool things we want to do" but
> I'm not quite convinced yet on *why* we want to do these and what the
> benefits are. I live in my own bubble of only few repositories I have to
> deal with, so if you tell me that this is more of an issue when working on
> mesa/drivers/whatever then I'll take that as argument.
>
These are some ideas of how to make the whole thing [build.sh/modular]
actually useful. I'm not saying that you/others have to do any of it.
If one is not willing to let build.sh/modular (and others) die, might
as well beat them into shape ?

Guess I'm just naive (hence the NOMAKE patch) and shouldn't bother :-(

-Emil