1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

  • [gentoo-dev] Current portage will now truncate your repo's git history

    From Florian Schmaus@21:1/5 to All on Thu Dec 15 20:30:01 2022
    This is a public service announcement that the recently stabilized
    portage version will truncate you repo's git history to 1.

    While this is a good thing for the majority of Gentoo users, it affects developers that develop in a git known to portage (like me). If I
    understand the portage maintainers vision correctly, then future portage
    will assume full control over its configured repositories and
    potentially perform destructive operations on them, for example "git
    clean" [1].

    I personally would prefer portage simply adjusting its behavior based on
    the owner of the repository. That is, if it's the 'portage' user then
    assume full control, and if it is a different user, then fall back to a preserving, conservative mode of operation. Unfortunately, for me, this
    idea was received skeptically at best in a recent discussion in #gentoo-portage.

    So this is a heads up for fellow developers using a similar workflow
    like me, that they are probably required to change their workflow to use PORTDIR_OVERLAY and multiple repositories on their system: a
    system-wide, managed by portage, and a dev repository (in your HOME),
    scoped in via PORTDIR_OVERLAY.

    As everyone knows, there is nothing better than to change the workflow
    that has served you well over multiple years. But apparently the PORTDIR_OVERLAY approach works well for others, so I am confident that I
    (and others) will be able to make the transition with a minimal amount
    of ranting. ;)

    - Flow



    1: https://github.com/gentoo/portage/pull/939

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Florian Schmaus@21:1/5 to Florian Schmaus on Thu Dec 15 21:00:01 2022
    On 15/12/2022 20.22, Florian Schmaus wrote:
    As everyone knows, there is nothing better than to change the workflow
    that has served you well over multiple years. But apparently the PORTDIR_OVERLAY approach works well for others, so I am confident that I
    (and others) will be able to make the transition with a minimal amount
    of ranting. ;)

    As it was pointed out that some consider my wording here inappropriate
    and/or rude, I want to apologize to everyone who was offended by the
    prior paragraph. I had

    https://xkcd.com/1172/

    in mind when writing it.

    I was also criticized for not providing a rationale for the behavior
    change in portage. The motivation is driven by the noble goal to make
    portage more user friendly and robust. Which I fully support. Just like
    I support shallow clones per default. I just believe portage should do a
    better job figuring out if it potentially messes with a "user-owned"
    repository and adjust its behavior accordingly. In a similar spirit I
    submitted https://github.com/gentoo/portage/pull/960

    - Flow

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Duncan@21:1/5 to All on Fri Dec 16 02:10:01 2022
    Florian Schmaus posted on Thu, 15 Dec 2022 21:40:19 +0100 as excerpted:

    On 15/12/2022 21.10, Toralf Förster wrote:
    On 12/15/22 20:22, Florian Schmaus wrote:
    o use PORTDIR_OVERLAY and multiple repositories on their system: a
    system-wide, managed by portage, and a dev repository (in your HOME),
    scoped in via PORTDIR_OVERLAY.

    Isn't this covered by /etc/portage/repos.conf/*

    Absolutely, but this requires a manual intervention from the user. And,
    of course, you can totally opt-out from portage managing (syncing) the repository, but then you have to take care of syncing yourself.

    The point is that with the new portage release, portage's behavior
    changes. And I would argue that portage should not, in its effort to
    become more user friendly, disregard ebuild-developer friendliness.
    Assuming it is achievable with a reasonable amount of additional code complexity.

    This bit me too, and making things worse, the truncate killed the git
    history that presumably had the answer I needed to fix it up.
    =:^( Fortunately I had a bit of a clue due to preemptively following the portage changelog where I had seen a hint, so I was able to dig it up
    again without the git log help that's definitely now my first instinct.

    Long story short and for the record, manual intervention indeed and I wish
    it had at least come with a news item, but here's the magic that fixed it
    for me.

    I had one of these previously, IIRC clone depth, but both are now needed.
    I put these in the [DEFAULT] section here because I run several overlays
    and I "want" access to proper git logs and history by default. (FWIW
    "want" is the polite, cooled down, version; the situation was considerably
    more sweary when I lost that history and instinctively I tried to look in
    the git history for why, but of course it was GONE!)

    repos.conf, [DEFAULT] (or [gentoo]) section:

    clone-depth = 0
    sync-depth = 0

    --
    Duncan - List replies preferred. No HTML msgs.
    "Every nonfree program has a lord, a master --
    and if you use the program, he is your master." Richard Stallman

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)