List Archive: gentoo-pms
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Sat, 19 Sep 2009 22:34:39 +0200
> > > Three small edits.
> > >
> > > - Removing a sentence that has no content, but spans three lines
> > No, the two sentences you're removing both have meaning:
> > The first says that it's ok for things to exist in
> > profiles/categories that don't have a directory
> Rationale for that?
People have done it in the past. It's also something that ends up
happening if categories are removed but people are syncing using
something that doesn't remove empty directories or directories that
still contain editor-created backup files lying around.
> > The second says that the package manager mustn't treat empty
> > categories and categories that don't exist differently.
> Not quite. What it says is that an empty and a non-existing category
> are equivalent, which doesn't explain how to treat them. Your current
> interpretation is already a large improvement.
The wording in PMS is sound, and says exactly what it needs to say. If
you'd like to propose clarifications to that wording that make it
easier to understand, feel free to do so, but the actual meaning
mustn't be changed.
> > Both are necessary.
> No, first one is confusing to read
How is it in any way confusing?
>, second one is a tautology.
It's not. It would be quite possible to write an implementation that
treats categories that don't exist as an error rather than an empty
category. We have to forbid such an implementation.
> > > - Simplifying the ebuild naming - since suffix is always "ebuild"
> > > there is no need to use an indirection
> > >
> > > - Fixing the list because "suffix is ebuild" now is redundant
> > Uhm. That part of the patch doesn't apply, and the revision against
> > which you're basing it isn't in the repository. Where did you get
> > 'b78fde2' from?
> Oh. I have over 900 lines diff already. Just pulling out the obvious
> changes before moving on to the more subjective and debatable ones.
If that 900 line diff is 'drop kdebuild', I suggest you don't bother. In
any case, please learn how to use 'git rebase' and only send patches
that are against current master -- even for patches that do apply, if
you're basing them upon unpublished changes, we can't use three way
merges when applying them.