On 27/04/11 04:14, Daniel Macks wrote:
[]
And while implementing this, I notice it already *is* allowed. Call it
a forward-looking feature or a bug in the implemenation (it's a little
of both), but fact is val does allow you to use PatchScript to remove
hardcoded /sw in upstream sources.
Am 18.04.2011 um 17:49 schrieb Daniel Macks:
On Mon, 18 Apr 2011 14:50:40 0200, Max Horn wrote:
Am 18.04.2011 um 14:49 schrieb Max Horn:
OK... anybody opposed? To summarize, this are the changes I
propose, each should be trivial to implement:
1) Drop the _warning_ when a package
Hi,
On Apr 26, 2011, at 12:17 PM, Max Horn wrote:
Am 18.04.2011 um 17:49 schrieb Daniel Macks:
On Mon, 18 Apr 2011 14:50:40 0200, Max Horn wrote:
Am 18.04.2011 um 14:49 schrieb Max Horn:
OK... anybody opposed? To summarize, this are the changes I
propose, each should be trivial to
On Tue, 26 Apr 2011 12:17:40 +0200, Max Horn wrote:
Am 18.04.2011 um 17:49 schrieb Daniel Macks:
There are some cases were the validator incorrectly complains about
perfectly fine packages. Currently, in such cases, the package
maintainer then is forced to either make weird unnatural hacks
On Tue, 26 Apr 2011 09:52:54 -0400, Daniel Macks wrote:
On Tue, 26 Apr 2011 12:17:40 +0200, Max Horn wrote:
Am 18.04.2011 um 17:49 schrieb Daniel Macks:
There are some cases were the validator incorrectly complains about
perfectly fine packages. Currently, in such cases, the package
Am 14.04.2011 um 14:33 schrieb Martin Costabel:
Max Horn wrote:
[]
Though I still agree that sometimes it's a bit tough to avoid the
package name... OK, I can't think of a concrete example right now, but
imagine you had a tool called image for image processing... using
the description
Am 14.04.2011 um 03:30 schrieb Daniel Macks:
[...]
Would be easy to make validator relax its Description test for obsolete
packages (there are already other special allowances for them that are
fatal otherwise).
That would be good then. Though actually, I wonder if we should relax the
Max Horn wrote:
[]
Though I still agree that sometimes it's a bit tough to avoid the
package name... OK, I can't think of a concrete example right now, but
imagine you had a tool called image for image processing... using
the description process alone seems a bit too minimalistic. So in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/5/11 8:34 AM, Max Horn wrote:
Hi there,
we have a bunch of obsolete packages, which typically only still exist to
smoothly and automatically transit users to their successor packages.
Typically, such packages depend on
On Apr 13, 2011, at 6:43 PM, Alexander Hansen wrote:
On 4/5/11 8:34 AM, Max Horn wrote:
Hi there,
we have a bunch of obsolete packages, which typically only still exist to
smoothly and automatically transit users to their successor packages.
Typically, such packages depend on
On Wed, 13 Apr 2011 19:50:30 -0400, Daniel Johnson wrote:
On Apr 13, 2011, at 6:43 PM, Alexander Hansen wrote:
On 4/5/11 8:34 AM, Max Horn wrote:
And so on. I would like to propose that all obsolete packages
receive a common, uniform description, namely:
OBSOLETE use FOO
After a brief discussion with dmacks on IRC, let me clarify some points:
My proposal is to change the description of obsolete packages to the following
*when it makes sense* and isn't too long:
Description: OBSOLETE use package 'FOO' instead
Some remarks:
* Of course there are cases where this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/6/11 7:19 AM, Max Horn wrote:
After a brief discussion with dmacks on IRC, let me clarify some points:
My proposal is to change the description of obsolete packages to the
following *when it makes sense* and isn't too long:
Description:
On Apr 6, 2011, at 7:19 AM, Max Horn wrote:
My view: I would prefer to follow the policy and rev up packages; if
a user still has them installed, this way they explicitly see that
they are about to update an obsolete package (something they may
have missed in the past due to a confusing
On Wed, 6 Apr 2011 08:32:44 -0400, Charles Lepple wrote:
On Apr 6, 2011, at 7:19 AM, Max Horn wrote:
My view: I would prefer to follow the policy and rev up packages; if
a user still has them installed, this way they explicitly see that
they are about to update an obsolete package
On Wed, 06 Apr 2011 08:26:40 -0400, Alexander Hansen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/6/11 7:19 AM, Max Horn wrote:
After a brief discussion with dmacks on IRC, let me clarify some points:
I agree with what Max says I said:)
I've got one thing to add:
Hi there,
we have a bunch of obsolete packages, which typically only still exist to
smoothly and automatically transit users to their successor packages.
Typically, such packages depend on fink-obsolete-packages, which marks them as
obsolete.
However, I just realized that end users may not be
PS: Some further IMHO problematic examples:
w3m-ssl0.5.2-1004 Upgrade package for w3m
- this sounds as if the package provides some extra upgraded functionality
for w3m.
openssl097 0.9.7m-6 Upgrade package for old
openssl097* layout
- similar
18 matches
Mail list logo
