[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
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Stefan Monnier, 2022/12/20
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Sean Whitton, 2022/12/20
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Sean Whitton, 2022/12/20
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Stefan Monnier, 2022/12/21
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Philip Kaludercic, 2022/12/21
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Stefan Monnier, 2022/12/21
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Sean Whitton, 2022/12/22
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Philip Kaludercic, 2022/12/24
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Sean Whitton, 2022/12/24
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Philip Kaludercic, 2022/12/24
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Dmitry Gutov, 2022/12/22
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Stefan Monnier, 2022/12/22
- Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package., Andreas Schwab, 2022/12/22