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
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
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, and
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 that
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 long
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 set of
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
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
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 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
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 @vapier QA
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
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, 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 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, 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 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 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, 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 regards,
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
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, 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, 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 discussion
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 experience
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 users
with a
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 file
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 package name).
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
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
29 matches
Mail list logo
