Ulrich Mueller <u...@gentoo.org> wrote: > The new ebuild is cat/foo-1-r0.1 then, and PF changes even > if the minor revision is ignored (namely, from foo-1 to foo-1-r0).
PF has to be filled correctly, of course: The versions foo-1 and foo-1-r0 are identical according to PMS and should thus lead to the same $PF. If this is currently not happening in portage, this is a bug which should be fixed, independently of whether minor revisions are introduced or not. Note that PR=0 in both cases. BTW: Even if PF would have the wrong value, this would not do any harm for minor revisions: If the minor revision has just changed, nothing is merged to the filesystem and /var/db/*/*/CONTENTS is unchanged, either. So nothing breaks in this case. If the user re-emerges the minor revision (and if PF would have the wrong value), then the minor revision would be visible to the user in the sense that the name of the Doc-Directory is influenced (and after a further minor revision bump, this revision number would be outdated). An arguable cosmetical issue, but nothing breaks, either. >> Actually, I still think that implementing dynamic deps correctly >> would be better, but minor revisions do not exclude this >> and are probably simpler to implement. > > The PM could just update the VDB whenever it detects that the metadata > of the ebuild has changed (relative to the VDB). You can get that > without introducing the additional complication of minor revisions. ...but by introducing all the additional complications Ian has mentioned. More precisely: What happens if new dependencies are introduced which are not satisfied? One has to face it: Portage must not just silently "update" the database and thus silently produce a /var/db which does not satisfy its own dependencies...
