Re: Supporting multiline Package-Requires header

[Achim Gratz <Stromeko@nexgo.de>]

Stefan Monnier writes:
> Why?  We're talking about the org.el that's in the tarball you send us.
> It doesn't have to be identical to the org.el in your VCS.

Yes, it should very much be identical.  If you look in org-version.el
you'll find the exact commit to check out from Git and any user would
have to expect that the files installed on her machine would match up
with the files in that tree.

> This said, it could also be identical to the one in your VCS without
> needing an extra commit: just make sure the version is changed as part
> of the last commit (since it's the last commit before a new release,
> it's not completely extravagant to expect that you'd often/usually know
> this commit will be used for a release and hence needs a change in the
> org.el's Version: header).

No, that simply doesn't work and I'm really not sure why you even
suggest it might.  The ELPA archive is created by a cron job every
Monday and we don't have a commit to org.el exactly every Monday, nor
would anyone touching org.el know if his commit is going to be the last
one before the tarball is created.

Again, this being a distributed VCS with many developers hacking away on
their own boxes and time and merging their stuff with both maint and
master, it would also ensure lots or merge conflicts that someone would
have to manually try and confine to the maint branch (each commit to
maint is expected to be merged into master as well).  No thanks, it was
a major improvement to get rid of this nonsense (also in the texinfo
files if you'd care to look) and we really don't want to go back there
for whatever reason.

As I said, if you insist on this we'll move to generate org.el and put
it's current content to a new file, but that will either take time or a
decision by Bastien that it's OK to do on maint.  Again, I can also put
these headers in any other generated file, be it org-pkg.el
org-version.el or anything else you want, which would be easier for us
to do and hence I expect it to be faster.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds