public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Lienhardt <michael.lienhardt@laposte.net>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Questions on overlays, repositories and PMS
Date: Sat, 24 Feb 2018 02:32:21 +0100	[thread overview]
Message-ID: <b7e65866-3021-8c76-b4f3-405bb468c6c4@laposte.net> (raw)
In-Reply-To: <CAAr7Pr_=nEj4PoT0+Mtq+1dQD=NP2g=TqyE=iEN=ZbxEfFzK7Q@mail.gmail.com>



Il 23/02/2018 20:37, Alec Warner ha scritto:
> My general observation is that Gentoo is not successful as an organization about deprecating and removing things. One area where Gentoo has done well is in EAPI and in PMS itself, with mostly-clear versioning and standards and whatnot. But in general if something worked 15 years ago, it probably still works today (doubly so for sys-apps/portage).
> 
> There is a different question when building a tool like yours if it is worth the effort to support things that are 15 years old and are possibly not used (particularly in cases where functionality was replaced). I'd recommend starting with the basic implementation and adding support for the 'older' formats when users ask for them; but this is mostly a trade-off in efforts. If your goal is to build 
> a "100% compatible" tool then you will probably need to support these edge cases.

You have a very good point.
I'd like to be complete (it's a side effect of working in formal methods), but it's quite unrealistic as I am the only developer in this project, and it's true that there are few technical design choices that were made in portage that I'd be happier not to implement.
I'd like to implement the /etc/portage/repos.conf system to remove as many hard coded references to /usr/portage in my code as possible.
Moreover, the /etc/portage/repos.conf system looks nice, modular with explicit dependencies and it almost unifies all the repositories (I don't really understand the need of a DEFAULT section).

If possible, I'd rather avoid implementing things that are deprecated, but like you pointed out, few are (portage seems to be always expanding with new/alternative functionalities).
The ones that are, like the /etc/portage/package.keywords file, seem to be still used (I've got a request to support it in my get_installation.sh script).
Additionally, there are two systems that I did not want to implement but had to: the IUSE_IMPLICIT and USE_EXPAND.
I didn't find any good documentation on these systems (nor the PMS nor https://dev.gentoo.org/%7Ezmedico/portage/doc/man/portage.5.html are very clear on the subject -- the PMS is still clearer), I tested a lot and looked at the portage implementation...
I don't understand the reason to implement these systems with bash variables expanded with prefixes, while many of the USE flag manipulation is done with dedicated files (use.*, package.use.*).
It really felt like an old design choice kept there because it worked, but which could be simplified.

On a similar topic, does anyone still have USE-related variables in his /etc/env.d folder? (https://wiki.gentoo.org/wiki/USE_ORDER)
It seems to me that portage's current effort is to have all configuration files in /etc/portage or in the profile.

Best,
Michael Lienhardt


  reply	other threads:[~2018-02-24  1:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-23 17:36 [gentoo-dev] Questions on overlays, repositories and PMS Michael Lienhardt
2018-02-23 18:09 ` Vadim A. Misbakh-Soloviov
2018-02-23 23:42   ` Michael Lienhardt
2018-02-23 19:37 ` Alec Warner
2018-02-24  1:32   ` Michael Lienhardt [this message]
2018-02-24 17:26     ` Roy Bamford
2018-02-24  3:26 ` Brian Dolbec

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=b7e65866-3021-8c76-b4f3-405bb468c6c4@laposte.net \
    --to=michael.lienhardt@laposte.net \
    --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