[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Questions on overlays, repositories and PMS
From:       Roy Bamford <neddyseagoon () gentoo ! org>
Date:       2018-02-24 17:26:08
Message-ID: 3XX9asnRGxSGX0PEfaZ5ve () EXnwKtXhR0lz9w6RKZAxc
[Download RAW message or body]


On 2018.02.24 01:32, Michael Lienhardt wrote:
> 
> 
> 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
> 
> 
> 
Michael,

'Support' can be as simple as nagging the user to move with the 
times and failing. 

I suspect that many older systems (including mine) are not updated
because it still works.

crossdev users may be familiar with this approach. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]