On Thu, 15 Aug 2013 07:50:16 +0800 Patrick Lauer <[email protected]> wrote:
> > Because if you want to allow multiple package managers as an option, > > If - but why would we do that? To give our users choice. http://www.gentoo.org/main/en/about.xml http://www.gentoo.org/main/en/philosophy.xml http://www.gentoo.org/doc/en/faq.xml#differences Gentoo is a meta distribution. > > then you need to have a clearly defined spec for them. The fact that > > portage implemented something > > that is not part of PMS, is not a PMS problem. > > It is a problem in the cases where portage had a feature *before* PMS > was defined, and then PMS tries to ignore it (see my last mail) Is it? Portage can still be PMS compliant as long as that feature is not in conflict with the PMS; that is, if it doesn't override a particular specification that is made in the PMS. The problem you perceive is not really Portage, but it rather has to do with the Portage tree; it is whether the Portage tree needs to be entirely PMS compliant that matters here. If it wasn't, then you could just use the feature; but as you see now, we can't due to this. Of course you can interpret this as an intermediate step as Portage <==> Portage tree <==> PMS and shorten it as the feature needing to be in the PMS; but well, it just makes me wonder if there's a way to have PM specific features in the Portage tree or perhaps even better in a separate tree. If there is it would break the chain and this wouldn't be a problem. But then the big question is whether we will want to do that? (Not that I want to suggest this myself, it is a brainstorm thought) > It is a problem when PMS does not define the configuration, so two > PMS-compatible programs can arrive at opposite results for any > operation. (Why does PMS not define config? Well, then paludis would > have a problem) Because the PMS is the interface with the Portage tree, not with the configuration on the system; it is not possible for such programs to arrive at opposite results for behaviors listed in the PMS. Theoretically, you can write a PM that does crazy non-sense; but why would you want to write that, and how at all is it a problem to you? > > So unless it becomes > > part of PMS, it can't be used in places where you expect PMS > > compliance. > > Unless PMS reflects reality it serves no purpose but ego stroking and > supressing deviant ideas that some people call "progress" Please read my response to that two of my mails ago in this sub thread; there is no such thing as reflecting reality, rather, you define it. The order in which things are done is Idea -> Discussion -> Consensus -> Specification -> Implementation and if you would reflect reality then you would swap the last three around which doesn't make sense, if you don't have a consensus and therefore no specification; then why would it already be implemented? > > If you want PMS to go away, and call portage the one-and-true PM for > > Gentoo, then it's probably something for the Council to decide. > > De facto it is like that - if it doesn't work with portage it gets > fixed, masked and/or removed. That is just a false perception, the PMS is a QA project as seen on http://www.gentoo.org/proj/en/qa/ http://www.gentoo.org/proj/en/qa/pms.xml and therefore its rationale applies; which means that as a matter of QA they expect it to work with the PMS in the first instance, and not so much with Portage in specific. So, this leads to the following QA words: This document aims to address both of these concerns by defining almost all aspects of what an ebuild repository looks like, and how an ebuild is allowed to behave. It is the PMS that addresses this, not Portage; although of course, Portage is such a reference implementation, but other PMs are as well; if a package can be shown to have PMS or QA issues, it indeed needs to get fixed, masked and / or removed. These occasions stem very much with "doesn't work with Portage" because Portage implements the PMS. > Using anything else might work, or not, but it also removes you from > support (e.g. #gentoo, bugs.gentoo.org (any maintainer is free to > ignore or RESO INVA bugs that are not filed with portage) and so on) Indeed, the developer is free to close bugs as invalid if the reported PMS or QA issue is likely a false positive; even when that is Portage. > Claiming that the absence of a written policy invalidates reality is a > rather amusing theory that makes little sense Policies are based on consensus, consensus are based on discussion; if you can not point me to a discussion with a clear consensus, then you can not make a claim in either direction. Don't make assumptions... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
