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
pgp8okkf_VHbW.pgp
Description: PGP signature
