Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12

[Rich Freeman]

On Fri, Aug 1, 2014 at 7:51 AM, Alexander Berntsen <bernalex@g.o> wrote:
> On 01/08/14 02:34, Rich Freeman wrote:
>> So, this is more than just a portage design question, and I think
>> it is fair for the Council to take up.  Obviously the feelings of
>> the portage maintainers should be carefully considered.
> Dynamic dependencies are not specified.

None of this stuff is specified, dynamic or static.  The only thing in
PMS is how to declare a dependency.  It says nothing about how a
package manager should rely on this.

As was pointed out, portage prerm is broken with both dynamic and
static deps (and in my last email I limited this to slot operator
deps, but in reality it is broken anytime it depends on linkage
whether the slot operator dep is expressed or not).  I don't think
that is a huge issue in practice, but I've yet to hear an example of
anything which is.

> As such, this is in fact a bug
> rather than a question of design.

So, at work I have the luxury of systems that have broken requirements
instead of just broken implementations, but for as good as PMS is it
falls very short of being a full functional requirement specification
for portage.  The lack of a specified function in PMS does not mean
that implementing this in portage is a bug.

>
> Personally, I am slightly surprised by the reactions and uproar this bug
> fix has caused. At my day job, we commend each other for fixing bugs,
> and express gratefulness for the effort.

The problem is that not all agree that dynamic dependencies are a bug.
It isn't obvious that static deps are specified behavior, and even if
it were specifications can be changed before software is released when
there is agreement that they're incorrect.

I am certainly grateful to the few that are continuing to contribute
to portage development, however!

Also, I apologize if this email comes across as antagonistic.  I'm a
bit on the fence regarding dynamic deps and mostly for practical
reasons.  I've yet to be convinced that they aren't workable (and this
may simply be because I haven't noticed the argument against them).
On the other hand, Michał's post has gone a long way towards
convincing me that removing them isn't that big of a deal, which
leaves open the option of taking them out for now and then trying to
come up with a cleaner implementation later.

>
> PMS does not specify dynamic dependencies. This means that if Portage
> uses dynamic dependencies, and tree hackers rely on this behaviour, we
> are needlessly making life difficult for users of other package
> managers. Consequently, Portage should strive to follow the PMS's
> intention as closely as possible. If you want to do some work on
> formulating how dependencies are handled, please use the gentoo-pms
> mailing list.

I haven't spotted anything in PMS that specifies or necessitates
static dependencies (citations are welcome).  The content of VDB is
not within PMS's scope, and that is where most of the impact of
dynamic dependencies resides.

>
> Tree policy, I'm afraid, has to adapt to Portage; not the other way
> around.

The reality is that both portage and the tree policy need to adapt to
the needs of the community, otherwise there won't be anybody around
maintaining either.  Nobody can change that - Portage team, PMS team,
or even the Council.  That is why we're better off focusing on
communicating the need for change and understanding its impact, and
not arguing about who gets to make the call.  It also isn't enough to
just tell people what they have to do to comply - they need to be
convinced that they're doing it for a reasonably good reason, or at
least that it was a debatable decision and the Council had to make a
call one way or the other.

I think that Michał has already taken some steps to make the impact of
changing more clear.  If we can just get a quick argument as to the
need for change I think that would be helpful.  It need not be
exhaustive - if there are 500 things that break with dynamic deps a
top 5-10 list should be more than sufficient.

Rich