From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: Patrick Lauer <patrick@gentoo.org>
Cc: gentoo-pms@lists.gentoo.org
Subject: Re: [gentoo-pms] tree-layout.tex small cleanup
Date: Sat, 19 Sep 2009 21:45:15 +0100 [thread overview]
Message-ID: <20090919214515.6b314a3f@snowmobile> (raw)
In-Reply-To: <200909192234.39415.patrick@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]
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.
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2009-09-19 20:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-19 20:15 [gentoo-pms] tree-layout.tex small cleanup Patrick Lauer
2009-09-19 20:25 ` Ciaran McCreesh
2009-09-19 20:34 ` Patrick Lauer
2009-09-19 20:45 ` Ciaran McCreesh [this message]
2009-09-19 20:56 ` Patrick Lauer
2009-09-19 21:08 ` Ciaran McCreesh
2009-09-19 22:03 ` Ulrich Mueller
2009-09-19 22:11 ` Ciaran McCreesh
2009-09-19 22:31 ` Andrew D Kirch
2009-09-19 22:38 ` Ciaran McCreesh
2009-09-19 23:19 ` Andrew D Kirch
2009-09-19 23:27 ` Ciaran McCreesh
2009-09-19 22:43 ` Ulrich Mueller
2009-09-19 22:54 ` Ciaran McCreesh
2009-09-19 23:07 ` Patrick Lauer
2009-09-19 23:16 ` Ciaran McCreesh
2009-09-19 22:48 ` Patrick Lauer
2009-09-19 23:03 ` Ciaran McCreesh
2009-09-19 23:26 ` Patrick Lauer
2009-09-19 23:35 ` Ciaran McCreesh
2009-09-20 0:37 ` Patrick Lauer
2009-09-20 0:44 ` Ciaran McCreesh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090919214515.6b314a3f@snowmobile \
--to=ciaran.mccreesh@googlemail.com \
--cc=gentoo-pms@lists.gentoo.org \
--cc=patrick@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox