public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Gerion Entrup <gerion.entrup@flump.de>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] multiversion ebuilds
Date: Sat, 12 May 2018 16:36:13 +0200	[thread overview]
Message-ID: <1796959.TKVFouW9oh@gump> (raw)
In-Reply-To: <23286.63590.355603.768432@a1i15.kph.uni-mainz.de>

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

Am Samstag, 12. Mai 2018, 16:21:26 CEST schrieb Ulrich Mueller:
> >>>>> On Sat, 12 May 2018, Gerion Entrup wrote:
> 
> > just an idea for now. But what you think about multiversion ebuilds?
> > Technically this could be realized with the following line in the
> > ebuild itself:
> > ```
> > VERSIONS=( 3.0.11 3.0.12 3.1 )
> > ```
> 
> > [...]
> 
> > The advantages of this idea I see are:
> > - Ebuilds are written in a multiversion manner anyway, and then get
> > copied (or linked?), so it can be made explicit.
> > - The diffs between different versions of ebuilds and the commit
> > history are way more readable.
> 
> That depends on the options you specify for git diff (e.g.,
> --find-renames, --find-copies, or --find-copies-harder).
This does not apply to the online diffs (see e.g. [1]). I assume that most users don't have
the git repository checked out.

> 
> > - The size of the tree reduces.
> 
> I very much doubt that (or at least it remains to be proven).
> 
> Currently, when an ebuild is copied for a version bump, it will reuse
> the same blob in the Git repository. With the scheme above, you would
> have to modify the ebuild, which would add a new blob for every
> version bump.
You are right, I've not thought about that. However, this is only true for
the repository not for the rsync copy most(?) users have and not for a checkout.

Gerion

[1] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d9397ab8d48feb4b1360be614da35fa2faae44d9


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2018-05-12 14:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-12 12:20 [gentoo-dev] [RFC] multiversion ebuilds Gerion Entrup
2018-05-12 13:47 ` Rich Freeman
2018-05-12 14:13   ` Gerion Entrup
2018-05-12 14:21 ` Ulrich Mueller
2018-05-12 14:36   ` Gerion Entrup [this message]
2018-05-12 15:23     ` Dennis Schridde
2018-05-12 14:24 ` R0b0t1
2018-05-12 14:38   ` Gerion Entrup
2018-05-12 19:49 ` Georgy Yakovlev
2018-05-15  9:32 ` Mathy Vanvoorden
2018-05-16  4:15   ` [gentoo-dev] " Duncan
2018-05-16  4:22     ` R0b0t1
2018-05-16  6:15       ` Martin Vaeth
2018-05-16  6:26 ` [gentoo-dev] " Paweł Hajdan, Jr.
2018-05-16  6:46   ` Ulrich Mueller
2018-05-16  7:12     ` Ulrich Mueller
2018-05-16  7:38 ` Michał Górny
2018-05-16 23:33   ` R0b0t1
2018-05-17 15:44   ` Gerion Entrup
2018-05-17 16:16     ` Rich Freeman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1796959.TKVFouW9oh@gump \
    --to=gerion.entrup@flump.de \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox