Re: [PATCH 1/1] fetch2: remove "." in the end

[Jason Wessel <jason.wessel@windriver.com>]

On 06/27/2016 08:51 AM, Richard Purdie wrote:
> On Mon, 2016-06-27 at 08:46 -0500, Jason Wessel wrote:
>> On 06/24/2016 08:15 AM, Richard Purdie wrote:
>>> On Fri, 2016-06-24 at 00:55 -0700, Robert Yang wrote:
>>>> From: Jason Wessel <jason.wessel@windriver.com>
>>>>
>>>> The filename can't be "foo." for MS Windows filesystem, it will
>>>> renamed
>>>> to "foo" automatically, so we can't upload sources like "foo." to
>>>> the
>>>> Windows server, remove "." in the end will fix the problem.
>>> This patch on its own is probably ok. What I worry about is that if
>>> I
>>> merge this, I'll then get all the follow ups which for example
>>> force
>>> lower or upper case everywhere, remove ":" characters from all
>>> filenames (including sstate?), remove various other characters and
>>> so
>>> on.
>>>
>>> We don't run on windows filesystems and we're not likely ever to be
>>> able to.
>>>
>>> So what are we aiming for here?
>>
>> It is compatibility with browsing and copying the bitbake/oe
>> directory structures + the download cache.  We certainly don't expect
>> to be building directly on Windows with a native bitbake. Today
>> however, you can directly use git on Windows and building with the
>> cross API's from a generated SDK.
> You haven't really answered my question though. If we fix this, how
> many other issues are we going to run into? Are we for example going to
> need to change the sstate filename field separator? Are there other
> filename issues we'll run into. Typically, someone sends a simple patch
> like this, then a couple more and then we suddenly find we've committed
> to rewriting half the system to "support windows filesystems".


This is a problem that was found in steady state maintenance from 5 years worth of using Windows as a cross application building environment from a derived platform build from a Linux environment.   There is no foreseeable plan to change what is there.   This is a "bug fix" to a problem which has existed for some time now. Unfortunately Robert blindly sent a patch on my behalf from an internal pastebin and it did not include how the problem was found or any of the original suggested solution discussion.   In that case the patch should have come from him and not me.

That being said I'll bring up some of the points of how the problem was discovered.

1) A git URI ended in a slash in a single recipe.

     My personal contention is that this is just wrong.
        A) Git didn't always have support for the "/" at the end
        B) In some cases this can not be used a push reference

     Evidence in the community shows that since 2014:
        A) git internally drops the slash and the right thing
        B) git hub started allowing https push with the trailing slash

2) Originally I proposed just adding a warning or error to bitbake for
      a trailing "/" and then fixing the single problematic recipe
      out of the 2900 we parse.

3) The OE download cache uses a direct translation of the URI
     A) Because there is community support for the trailing / on URI
          perhaps fixing the cache is a better approach
     B) The fetcher cache creates a bare clone of a git which
          in turn does not need the trailing slash
     C) I created and tested a simple patch with the fetcher

4) Robert sent this patch from one of my pastebin possibilities instead of
     having an open discussion on the topic first.


>
> I'm going to refuse to do this piecemeal. I'd like a thought out
> proposal about exactly which files we need to support on windows and
> how much of bitbake we're expecting to be able to use (or which class
> code/tools) before we start adding patches.

I do not believe there is any proposal to write.  In general what we have for Windows today has worked fine.  It has been working for the last 5 years.   We regression test any changes to the master branch against the same Windows SDK policy we have been using and are not making any changes to that policy or adding additional functionality.

Do you believe we are standing on some kind of slippery slope?

Prior to hitting this problem with the single recipe we did not even have a test for a directory ending in a dot.  Case folding on the other hand has been tested and the limitations and work arounds are documented and already implemented.  I see no need to change anything else.  If you look at this another way, a couple line fix to a routine where a corner case was found after 5 years of use really isn't too bad.

Cheers,
Jason.