Re: [Mingw-cross-env-list] How to write .mk for libraries that have no source releases?

[Volker Grabsch]

Mark Brand <address@hidden> schrieb:
>>>> I'd like to write a .mk for a library which is only git available (
>>>> http://www.videolan.org/developers/libbluray.html ).
>>>> How can I write $(PKG)_URL variable and $(PKG)_UPDATE section?
[...]
>> We'll have to find a proper solution to this.
>>
>> One helpful detail is that the Git web interface allows for
>> downloading a certain version as tarball. See below for my
>> thoughts about using hashes as version numbers.
>
> I agree it makes sense to use generated tarballs, assuming a good  
> solution to the hash problem.

I put this issue on StackOverflow, but I didn't get a really
enlightening answer there, either:

    http://stackoverflow.com/questions/4296357

So I'll stick with the least unclean solution I came up with:
to pipe the downloaded file through an uncompressor and recompress
it with timestamps turned off (gzip -n):

    http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/59067afae1a4

Of course, this fix has to be activated explicitly for each
package that needs it:

    $(PKG)_FIX_GZIP := yes

> One thing you might want to consider is whether each new commit in the  
> git repo should necessarily be seen as an "upgrade".

I think we should upgrade from time to time, but we shouldn't
upgrade on every little commit.

Note that this is what we're currently doing anyway, because
we have a very similar situation with ImageMagick [1]  which
provides a new version every few days.

> Depending on how  
> you look at this, it might make sense to use a well-tested generated  
> tarball from the git service as a sort of baseline "release". An option  
> would be to put later less well-tested commits in a patch file, so they  
> could easily be undone in case of trouble. It partly depends on whether  
> the mingw-cross-env packager wants to play the role of release manager  
> for the package in question.

This is an interesting idea, and of course anyone can do that by
now, as the Git tarball issue is solved. So this is mostly independent
from the current discussion.

However, I also think that this would go too far, as I'm currently
trying to avoid roles like "release manager for package foo". One
of the design goals of mingw-cross-env is to be manageable by a
single person, which is an important step towards longevity and
sustainability.

Nevertheless, this may happen for certain packages, and in case
of an inactive "release manager", we could always switch that
package back to its latest release, or similar.


Greets,
Volker


[1] BTW, I recommend using GraphicsMagick instead of ImageMagick,
    and I'll add GraphicsMagick mingw-cross-env in the near future.)

-- 
Volker Grabsch
---<<(())>>---