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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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".

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.

Cheers,

Richard