Hi,
TLDR: Guillem is right, I'm wrong. Please leave everything as it is. :)
I came to the conclusion that the meaning/semantics of the new syntax can best
be summarized as:
- by default no build profile is set
- multiple build profiles can be activated at the same time
- the restriction synta
Hey!
[ Undusting, before it gets lost in my postponed mail box, along other
old corpses there. ]
On Wed, 2013-12-04 at 14:47:38 +0100, Johannes Schauer wrote:
> I see you attributed me as the author of the patch but please note that as
> noted in the email in which I submitted the patch, it was
Hi Guillem,
Quoting Guillem Jover (2014-02-06 23:38:10)
> Oh! I didn't realize those were stalled due to this, I don't think it was
> clear to me given your reply.
no, at that point nothing was stalled yet :)
Sorry, I didnt want to make an accusation in my last email but I can see how it
sounded
Hi!
On Thu, 2014-02-06 at 18:52:36 +0100, Johannes Schauer wrote:
> Quoting Johannes Schauer (2013-12-04 14:47:38)
> > > I've also changed the restrictions logic to match the arch one, because
> > > the
> > > one proposed here didn't make sense to me in some cases,
> >
> > I spent quite some tim
Hi Guillem,
Quoting Johannes Schauer (2013-12-04 14:47:38)
> > I've also changed the restrictions logic to match the arch one, because the
> > one proposed here didn't make sense to me in some cases,
>
> I spent quite some time on it because it's indeed quite confusing.
again two months passed.
Hi Guillem,
Quoting Guillem Jover (2013-12-04 08:48:15)
> Ok, here's the reworked patch I've got locally which will be included in
> today's upload (after I wake up), and the diff against yours.
Thanks a lot for working on this! :D
I see you attributed me as the author of the patch but please no
Hi,
On Wed, 04 Dec 2013, Guillem Jover wrote:
> There's a thing I'm not entirely sold on yet, and will probably rethink
> it once I wake up, that's the name of the output field, currently
> Build-Profiles, but I'm pondering on Built-For-Profiles for example.
+1 for something else than Build-Profi
+++ Guillem Jover [2013-10-21 07:31 +0200]:
> Hi,
>
> On Tue, 2013-09-17 at 12:31:17 +0200, Johannes Schauer wrote:
> > To get this issue moving, I have attached a patch which implements the <>
> > version of the proposal. The patch is based upon one by wookey and pehjota
> > [1]
> > and adds tes
Hi Guillem,
Quoting Guillem Jover (2013-10-21 07:31:23)
> Sorry, I lost track of this, was meaning to get into this but got pulled into
> something else. I've added it now to my TODO list for stuff do deal with
> before 1.17.2 (a release I don't really want to drag much more than a week or
> two a
Hi,
On Tue, 2013-09-17 at 12:31:17 +0200, Johannes Schauer wrote:
> To get this issue moving, I have attached a patch which implements the <>
> version of the proposal. The patch is based upon one by wookey and pehjota [1]
> and adds testcases, namespace support and the ability to activate more th
Hi Guillem,
Quoting Guillem Jover (2013-08-16 14:15:04)
> > The current iteration of the Spec, after some refinement at debconf, is
> > here: https://wiki.debian.org/BuildProfileSpec
>
> I've not checked that yet, will try to do that during this weekend.
> ISTM I had an issue with the new field b
Hi,
Quoting Wookey (2013-08-27 13:58:22)
> +++ Guillem Jover [2013-08-16 14:15 +0200]:
> > I've not checked that yet, will try to do that during this weekend. ISTM I
> > had an issue with the new field being Profile instead of Build-Profile, for
> > example. Will need to check my notes.
>
> The
+++ Guillem Jover [2013-08-16 14:15 +0200]:
> Hi!
>
> On Fri, 2013-08-16 at 02:59:45 +0100, Wookey wrote:
> > In the interests of making some progress, I suggest that we simply say
> > that arches and profiles can't be mixed in a [], as otherwise we'd
> > have to change the dpkg API, and no-one se
Wookey wrote:
> +++ Guillem Jover [2013-08-16 14:15 +0200]:
>> I've been pondering about the (old) updated proposal, and while I can
>> see Ian's argument and can agree with the problems he presents, I
>> can't really see using a syntax like «pkg [foo] [bar]» as something
>> desirable given the cu
+++ Guillem Jover [2013-08-16 14:15 +0200]:
> > The current iteration of the Spec, after some refinement at debconf, is
> > here:
> > https://wiki.debian.org/BuildProfileSpec
>
> I've not checked that yet, will try to do that during this weekend.
> ISTM I had an issue with the new field being Pro
Hi!
On Fri, 2013-08-16 at 02:59:45 +0100, Wookey wrote:
> In the interests of making some progress, I suggest that we simply say
> that arches and profiles can't be mixed in a [], as otherwise we'd
> have to change the dpkg API, and no-one seems very keen on that.
>
> Yes it would be nicer, but
Hi,
Quoting Wookey (2013-08-16 03:59:45)
> In the interests of making some progress, I suggest that we simply say that
> arches and profiles can't be mixed in a [], as otherwise we'd have to change
> the dpkg API, and no-one seems very keen on that.
In addition, once needed, mixing architectures
+++ Johannes Schauer [2013-05-18 10:13 +0200]:
> Hello again,
>
> Quoting David Kalnischkies (2013-04-23 20:01:10)
> > On Tue, Apr 23, 2013 at 12:14 AM, Johannes Schauer
> > wrote:
> > > Otherwise, the advantage of the second is, that it prevents mixing
> > > different scopes in one [...] qualif
Hello again,
Quoting David Kalnischkies (2013-04-23 20:01:10)
> On Tue, Apr 23, 2013 at 12:14 AM, Johannes Schauer wrote:
> > Otherwise, the advantage of the second is, that it prevents mixing
> > different scopes in one [...] qualifier and is also a bit shorter (but also
> > more irregular).
>
Hi,
Quoting David Kalnischkies (2013-04-28 17:54:41)
> "=" is in so far taken as a separator between package name and version.
>
> So we would get something like:
> apt-get install (XY)*(:)?(=)?
>
> At least apt-get would need to decide if "foo:armel=1.0-1" is a profile or
> an architecture and
On Sun, Apr 28, 2013 at 4:40 PM, Johannes Schauer wrote:
> Quoting David Kalnischkies (2013-04-28 14:27:12)
>> On Tue, Apr 23, 2013 at 9:15 PM, Johannes Schauer wrote:
>> My answer: X=~ and Y=. (or anything else expect : really)
>> As this is something you will have potentially as output in APT/d
Hi,
Quoting David Kalnischkies (2013-04-28 14:27:12)
> On Tue, Apr 23, 2013 at 9:15 PM, Johannes Schauer wrote:
> > Indeed it is, but the dot would be forbidden to be part of scope names and
> > their values and the package name would be separated from a potential
> > "." by a colon like: ":.", n
On Tue, Apr 23, 2013 at 9:15 PM, Johannes Schauer wrote:
>> > Since this topic is much about being future proof, I also thought about the
>> > choice of the ":" (colon) character to separate the scope from the value in
>> > each label like: ":". If the colon is used for this purpose,
>> > then it
On Tue, 23 Apr 2013, Johannes Schauer wrote:
> Raphael, your argument is very convincing and I am now even more in favour of
> Ian's proposal, thanks! Can you list some of those other use cases you said
> you
> can imagine? Maybe that helps to better decide upon the following:
I gave two already.
Hi David,
Quoting David Kalnischkies (2013-04-23 20:01:10)
> I don't see the benefit of enforcing rules on which scopes can be mixed in
> one […] qualifier. Sure, you can make it a bit simpler, but I am not sure if
> it isn't biting us back one day if we can't mix scopes. Always a bit hard to
> im
On Tue, Apr 23, 2013 at 12:14 AM, Johannes Schauer wrote:
> Quoting Raphael Hertzog (2013-04-21 21:49:55)
>> So I tend to agree with Ian, it would be much more future-proof to have a
>> generic syntax instead of introducing another metacharacter.
>>
>> (Furthermore the ">" and "<" are already used
Hi,
Quoting Raphael Hertzog (2013-04-21 21:49:55)
> So I tend to agree with Ian, it would be much more future-proof to have a
> generic syntax instead of introducing another metacharacter.
>
> (Furthermore the ">" and "<" are already used in many dependencies, so
> it would not really stand out i
Hi,
On Fri, 19 Apr 2013, Johannes Schauer wrote:
> 1. How bad is the spending of a new metacharacter and how needed is the
>namespace system? If there is no other usecase for these namespaces to
>conditionally include/exclude dependencies, then why introduce it? Is the
>fact that we ca
28 matches
Mail list logo
