From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6C07B1382C5 for ; Sun, 21 Jun 2020 01:22:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C4860E0943; Sun, 21 Jun 2020 01:21:57 +0000 (UTC) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 815E5E092F for ; Sun, 21 Jun 2020 01:21:57 +0000 (UTC) Received: by mail-ed1-f47.google.com with SMTP id e22so141302edq.8 for ; Sat, 20 Jun 2020 18:21:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+8HCY8KN9llJXyZCiKekGK8JZ9S5M8UsEOVjYqebGfY=; b=OmDSnnbWcdaw8tTZ6p2qfNu1ltMMSDTnDirM0zOIOmTNXsucIos0aq6laVX3NLxbMa A5Q/W69g1PgROgMpn1iHBsZrzK2vSUpHcpj1SgpYAQyLSkC+utwvllsMHRmdmXeBjqYP euiy6GgTV2ao0okh40Qy4oD9cippwPs9IVlIh8aDs5HmFYf4mhpXkpAMdmQr0awiRPLx gMt4Zia/DErR+NK0xOaPGEF00KbLkAL12h6Tg5zv+oKWk/x261zadjnnfjaudNfBf0q6 WOWMNs+68sONpVYWAM8ADVB/39hG2Ft3DQLEOWbgptcM06OXvHZSji6p6/XTDL0D9EIC 4ZxQ== X-Gm-Message-State: AOAM532t5TTln9/Fl124l/p0f3XvuHAvLboWubKDcvmuzApwxj0rAPO3 WP6KieE1QMAshHp8fLOASXN9SJ13sjFgLqirw4vLn7OX2HY= X-Google-Smtp-Source: ABdhPJyX8Xr9ZHlAO+MrpOW5jrqAHiyd4awTrfNSs8O8V/tVj90+g7qSunFLDGyIHKGV1DrGDploQzmR/fwgDMA/jPw= X-Received: by 2002:a50:c90d:: with SMTP id o13mr4248131edh.338.1592702515787; Sat, 20 Jun 2020 18:21:55 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20200620040430.GA31108@waltdnes.org> <45f40170-7b4d-19d6-58a5-bdacc7333d65@gmail.com> <87d05tzhuj.fsf@wedjat.horus-it.com> <3cf8f8d8-2442-dde2-a703-f6ab4b76beb2@gmail.com> In-Reply-To: <3cf8f8d8-2442-dde2-a703-f6ab4b76beb2@gmail.com> From: Rich Freeman Date: Sat, 20 Jun 2020 21:21:44 -0400 Message-ID: Subject: Re: [gentoo-user] What's with all these "acct-group" ebuilds recently? To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: f2c10cb1-00d2-4cc3-a899-bb75fc3daa7b X-Archives-Hash: 582cfb08160d67b6298015443c9f4e26 On Sat, Jun 20, 2020 at 7:06 PM Daniel Frey wrote: > > You just pointed out the ambiguity. > > Emerging a package solely by its name worked 99.9% of the time before > this change. > > Now new users get the fun of "Gee, which one is the one I actually > want?" MythTV is a fairly clear one to figure out, but other packages > aren't. Honestly, your word of "ambiguity" was somewhat ambiguous. I had no idea what you were talking about in your original post. :) I think this is actually a fair criticism. Not so much that it isn't clear which one to install, but rather that this system does cause you to have to use full cat/pkg atoms when previous pkg alone would have worked. There have always been packages where this is necessary, but this has made this more common. I don't think this was really something anybody thought of at the time - perhaps somebody might have suggested a tweak at the time if it had been. As others have pointed out you could just tweak portage to ignore the account category when expanding incomplete atoms to restore the previous behavior. In any case, as to why this system was devised just read: https://www.gentoo.org/glep/glep-0081.html It hasn't been communicated to users much because it tends to have little impact on them. Before packages just created accounts when needed. Now they pull in an account package that does it instead. If the user doesn't care to manage the uids/gids for various accounts they don't need to worry about how this works. If they do want to manage these themselves they can either create those accounts manually beforehand, or override these packages. It is also much more obvious when a new package is going to create additional accounts, so users who care about such things can intervene before merging the packages. Overall I'd say it is a net improvement. It of course led to a whole bunch of these packages being installed when the change was made, but these would generally be no-ops for existing users. -- Rich