emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package


From: Sean Whitton
Subject: Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package.
Date: Tue, 20 Dec 2022 22:42:19 -0700
User-agent: Gnus/5.13 (Gnus v5.13)

Hello,

On Wed 21 Dec 2022 at 12:01AM -05, Stefan Monnier wrote:

>> Perhaps we could overcome this particular limitation in the scripts.
>> How about adding :files or :include, or similar, where if that's
>> present, then only files matching the globs listed are taken up, and
>> everything else is ignored?
>
> The problem is not with the tarball, but with the Git side.  (Non)GNU
> ELPA is not just an archive of tarballs, but it's built around Git
> repositories hosting the relevant code and its full history.
>
> While I hope Git grows support for "partial clones" (or more likely is
> superseded by something else which does support such things), the
> current situation is that you just can't do that.  Which means
> `elpa-diffs` will be spammed with irrelevant commit to the non-Emacs
> part of Notmuch, for example, and `package-vc` will still have to
> download the 10MB of Notmuch's repository just to get at the relevant
> 0.5MB.

Couldn't we filter out mail to elpa-diffs where the diffs only touch
files that aren't included using :files/:include?

Your point about package-vc identifies a disadvantage of using
upstream's history, to be sure, but I think it's outweighed by the value
of distributing upstream's actual history (arguably it's part of the
preferred form for modification for the code).

> The closest we can get, AFAIK, is to run an interposer repository
> which fetches from https://git.notmuchmail.org/git/notmuch and filters
> the `emacs` subtree into a new branch, and then add *that* branch to
> `elpa-packages`.  Of course, that creates a whole parallel history, so
> it may end up biting us down the line, but I think given the current
> situation it'd the "least wrong" way to do it (The Right Way being if
> they do that split upstream and then use the new branch as the
> official upstream).

Is it a hard requirement that the updates be automatic?  Couldn't we
just manually import the emacs/ subdirectory to the branch whenever
upstream make a release?  It doesn't happen every week, and it could be
scripted.

> "0.37" of what?  Remember we're talking about `nongnu.git` which contains
> *all* the NonGNU ELPA packages.  So, upstream tags don't make much sense
> there (and for that reason also they're not pulled from upstream).
>
>> isn't that okay?
>
> [ And hence: no, it's not okay, I'm afraid.  ]

Ah right, thank you.

-- 
Sean Whitton



reply via email to

[Prev in Thread] Current Thread [Next in Thread]