<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 8, 2022 at 12:51 PM samuel ammonius <<a href="mailto:sfammonius@gmail.com">sfammonius@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Bug fixes don't change the entire package, only the executable, so<div>why can't apps just be programmed to update themselves? There</div><div>could be precompiled binaries stored on the git repos of each project</div><div>for a few CPU architectures, or maybe the app could even recompile</div><div>itself inside /tmp since most systems KDE runs on come with a compiler</div><div>by default (and macros could also be stored so that apps have the</div><div>same configuration throughout updates).</div></div></blockquote><div><br></div><div style="font-family:monospace" class="gmail_default">That depends entirely on whether the fix was in the executable or a library that it links to. If a library we can't be <br></div><div style="font-family:monospace" class="gmail_default">updating libraries willy nilly on user devices. Plus think about how it was built, which use flags in gentoo, which <br></div><div style="font-family:monospace" class="gmail_default">compile flags, etc. Which distribution specific patches were applied. Once you take all that into account there are many</div><div style="font-family:monospace" class="gmail_default">many ways to build kde applications.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Cheers,</div><div>Sam</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 8, 2022 at 11:58 AM Heiko Becker <<a href="mailto:heiko.becker@kde.org" target="_blank">heiko.becker@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thursday, 8 September 2022 13:59:43 CEST, Ahmad Samir wrote:<br>
> From the git-archive manual page:<br>
><br>
> «git archive behaves differently when given a tree ID versus <br>
> when given a commit ID or tag ID. In the first case the current <br>
> time is used as the modification time of each file in the <br>
> archive. In the latter case the commit time as recorded in the <br>
> referenced commit object is used instead. Additionally the <br>
> commit ID is stored in a global extended pax header if the tar <br>
> format is used; it can be extracted using git get-tar-commit-id. <br>
> In ZIP files it is stored as a file comment.»<br>
<br>
Before anybody tries that *now*, at least for Gear the tarballs are <br>
currently created with git archive --remote=kde:$repo $branch ..<br>
So they currently won't have that information.<br>
<br>
Regards,<br>
Heiko<br>
<br>
</blockquote></div>
</blockquote></div></div>