On Tuesday 28 February 2006 15:16, Marius Mauch wrote:
> Check your mail archives for the old discussions about distfile name
> mangling (short version: a lot of stuff relies on distfile-name ==
> basename(src_uri), also if at all this would only be a long term
> solution due to compat issues invol
Paul de Vrieze wrote:
On Sunday 26 February 2006 22:29, Robin H. Johnson wrote:
On Fri, Feb 24, 2006 at 02:19:40PM +, Ciaran McCreesh wrote:
Side note: if the packages in question are fetch restricted, you're
screwed, and will not be able to add them to the tree.
Actually, there is a so
On Mon, Feb 27, 2006 at 04:34:00PM +, Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 11:05:00 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> wrote:
> | Is there any valid reason that we can't have portage do this
> | automatically. This particular way is very user-un-friendly.
> There's exactly one
On Mon, 27 Feb 2006 10:46:23 -0600 Lance Albertson
<[EMAIL PROTECTED]> wrote:
| Where is this general consensus documented (other than an email sent
| out a few days ago). I'd have to go with Paul on this assumption. I
| don't see the problem with keeping a package such as stu's in portage
| as lon
Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 11:02:57 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> wrote:
> | On Sunday 26 February 2006 22:40, Ciaran McCreesh wrote:
> | > The issue is whether you have the right to leave broken packages in
> | > the tree. I don't see any policy document granting you
On Mon, 27 Feb 2006 11:05:00 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
wrote:
| Is there any valid reason that we can't have portage do this
| automatically. This particular way is very user-un-friendly.
There's exactly one set of packages affected, and they're closed source
and non-repackagable.
On Mon, 27 Feb 2006 11:02:57 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
wrote:
| On Sunday 26 February 2006 22:40, Ciaran McCreesh wrote:
| > The issue is whether you have the right to leave broken packages in
| > the tree. I don't see any policy document granting you that right.
|
| The general con
On Sunday 26 February 2006 22:29, Robin H. Johnson wrote:
> On Fri, Feb 24, 2006 at 02:19:40PM +, Ciaran McCreesh wrote:
> > Side note: if the packages in question are fetch restricted, you're
> > screwed, and will not be able to add them to the tree.
>
> Actually, there is a solution for this,
On Sunday 26 February 2006 22:40, Ciaran McCreesh wrote:
> The issue is whether you have the right to leave broken packages in the
> tree. I don't see any policy document granting you that right.
The general consensus over the years has been that if something cannot be
fixed due to portage proble
Daniel Ostrow wrote:
> On Sun, 2006-02-26 at 22:17 +, Stuart Herbert wrote:
>
>>On Sun, 2006-02-26 at 17:02 -0500, Daniel Ostrow wrote:
>>
>>>That would work for fetch restricted packages, not nomirrored ones.
>>>
>>>--Dan
>>
>>/me nods. That's what we'll have to do. Unfortunately, it leaves
On Sun, 2006-02-26 at 22:17 +, Stuart Herbert wrote:
> On Sun, 2006-02-26 at 17:02 -0500, Daniel Ostrow wrote:
> > That would work for fetch restricted packages, not nomirrored ones.
> >
> > --Dan
>
> /me nods. That's what we'll have to do. Unfortunately, it leaves users
> with a worse expe
On Sun, 26 Feb 2006 22:13:32 + Stuart Herbert <[EMAIL PROTECTED]>
wrote:
| On Sun, 2006-02-26 at 21:40 +, Ciaran McCreesh wrote:
| > The issue is whether you have the right to leave broken packages in
| > the tree. I don't see any policy document granting you that right.
|
| From a discuss
On Sun, 26 Feb 2006 22:17:33 + Stuart Herbert <[EMAIL PROTECTED]>
wrote:
| On Sun, 2006-02-26 at 17:02 -0500, Daniel Ostrow wrote:
| > That would work for fetch restricted packages, not nomirrored ones.
|
| /me nods. That's what we'll have to do. Unfortunately, it leaves
| users with a worse
On Sun, 2006-02-26 at 17:02 -0500, Daniel Ostrow wrote:
> That would work for fetch restricted packages, not nomirrored ones.
>
> --Dan
/me nods. That's what we'll have to do. Unfortunately, it leaves users
with a worse experience than before, but until I can find a way to reach
the QA team and
On Sun, 2006-02-26 at 21:40 +, Ciaran McCreesh wrote:
> The issue is whether you have the right to leave broken packages in the
> tree. I don't see any policy document granting you that right.
From a discussion in #-portage, I understand that ferringb has already
told the QA team that file cla
On Sun, 2006-02-26 at 21:54 +, Stuart Herbert wrote:
> On Sun, 2006-02-26 at 13:29 -0800, Robin H. Johnson wrote:
> > Simply tell the user to download X and place it in $DISTDIR renaming it
> > to X-foo-bar, where's you've chosen X-foo-bar to avoid conflicts.
>
> That works for me.
>
> Best r
On Sun, 2006-02-26 at 13:29 -0800, Robin H. Johnson wrote:
> Simply tell the user to download X and place it in $DISTDIR renaming it
> to X-foo-bar, where's you've chosen X-foo-bar to avoid conflicts.
That works for me.
Best regards,
Stu
--
Stuart Herbert
On Sun, 26 Feb 2006 21:30:22 + Stuart Herbert <[EMAIL PROTECTED]>
wrote:
| On Sun, 2006-02-26 at 21:04 +, Ciaran McCreesh wrote:
| > Ok, so given that this is a closed source application, if upstream
| > won't cooperate on something as simple as this, why do you expect
| > them to cooperate
On Sun, 2006-02-26 at 21:04 +, Ciaran McCreesh wrote:
> Ok, so given that this is a closed source application, if upstream
> won't cooperate on something as simple as this, why do you expect them
> to cooperate with you on bugs or security issues?
That's not the issue here. The issue here is
On Fri, Feb 24, 2006 at 02:19:40PM +, Ciaran McCreesh wrote:
> Side note: if the packages in question are fetch restricted, you're
> screwed, and will not be able to add them to the tree.
Actually, there is a solution for this, and it's reasonable logical.
Don't use the same name that upstream
On Sun, 26 Feb 2006 20:46:37 + Stuart Herbert <[EMAIL PROTECTED]>
wrote:
| On Sun, 2006-02-26 at 20:00 +, Ciaran McCreesh wrote:
| > Then you must talk to upstream and get them to change their ways.
|
| Already covered in the (growing) discussion in bug #123926. UPSTREAM
| have previously
On Sun, 2006-02-26 at 20:00 +, Ciaran McCreesh wrote:
> Then you must talk to upstream and get them to change their ways.
Already covered in the (growing) discussion in bug #123926. UPSTREAM
have previously been contacted over the issue, and have not changed
their release policy.
> We don't
On Sun, 2006-02-26 at 14:56 -0500, Mike Frysinger wrote:
> that's because it's common sense ... filename collisions just dont work
> -mike
This set of packages has been this way since October 2003, and if it was
a real problem for users, you'd see that reflected in bugzilla and in
the forums. It
> I'll contact the council separately, and ask that they look at two
> things:
>
> a) What the QA team is and isn't empowered to do
> b) The approval process that the QA team must follow before imposing
> tree-wide changes on other developers.
According to prior council meeting logs:
15:14 <@vap
On Sun, 26 Feb 2006 19:45:41 + Stuart Herbert <[EMAIL PROTECTED]>
wrote:
| On Fri, 2006-02-24 at 14:19 +, Ciaran McCreesh wrote:
| > Two ways this one can occur.
|
| [snip]
|
| Third way ... upstream is a provider of commercial software, and
| releases different editions of the same softw
On Sunday 26 February 2006 14:45, Stuart Herbert wrote:
> Also, I cannot find this SRC_URI rule (as being applied by the QA team)
> in any official Gentoo policy document.
that's because it's common sense ... filename collisions just dont work
-mike
--
gentoo-dev@gentoo.org mailing list
On Fri, 2006-02-24 at 14:19 +, Ciaran McCreesh wrote:
> Two ways this one can occur.
[snip]
Third way ... upstream is a provider of commercial software, and
releases different editions of the same software with identical
filenames.
> Side note: if the packages in question are fetch restricte
On Saturday 25 February 2006 22:29, Drake Wyrm wrote:
> > What about introducing a new variable in the ebuild file: DIST_PREFIX
> > that has as default value ${PN}. This should not break anything for
> > unaware portage versions. For aware portage versions, the files would
> > be retrieved from ${D
Paul de Vrieze <[EMAIL PROTECTED]> wrote:
> On Friday 24 February 2006 15:19, Ciaran McCreesh wrote:
[snip]
> > To avoid this, ensure that your packages use versioned SRC_URI
> > component names, and that the name part is something that's
> > reasonably likely to be unique (e.g. includes the packag
On Friday 24 February 2006 15:19, Ciaran McCreesh wrote:
> Two ways this one can occur.
>
> Way the first: foo-1.0 has a file in SRC_URI called foo.pdf. Then
> foo-1.1 comes along, and has a different foo.pdf.
>
> Way the second: foo-1.0 has a file called examples-1.0.tar.bz2. bar-1.0
> also has a
Ciaran McCreesh wrote:
-snip-
> Current offenders shall be receiving bugs shortly, since That Which
> Shall Not Be Named now checks for this.
>
The One Tool To Rule Them All? TOT4A -> TOTAL
--
Doug Goldstein <[EMAIL PROTECTED]>
http://dev.gentoo.org/~cardoe/
signature.asc
Description: OpenPGP
Ciaran McCreesh wrote:
Two ways this one can occur.
Way the first: foo-1.0 has a file in SRC_URI called foo.pdf. Then
foo-1.1 comes along, and has a different foo.pdf.
Way the second: foo-1.0 has a file called examples-1.0.tar.bz2. bar-1.0
also has a file called examples-1.0.tar.bz2.
To avoid
Two ways this one can occur.
Way the first: foo-1.0 has a file in SRC_URI called foo.pdf. Then
foo-1.1 comes along, and has a different foo.pdf.
Way the second: foo-1.0 has a file called examples-1.0.tar.bz2. bar-1.0
also has a file called examples-1.0.tar.bz2.
To avoid this, ensure that your pa
33 matches
Mail list logo
