2010/1/31, Hussam Al-Tayeb :

Or simply tell him the the package kernel-headers was renamed to linux-api-headers?

Nope, pacman already said him that. :-) -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it

On Sun, Jan 31, 2010 at 11:26:02PM +0100, Giovanni Scafora wrote:

2010/1/31, Hussam Al-Tayeb :

...

Or simply tell him the the package kernel-headers was renamed to linux-api-headers?

Nope, pacman already said him that. :-)

So, if pacman ever asks: Replace cdrkit by cdrtools ? [Yn] that means that cdrkit has been renamed to cdrtools ? :-) (/me runs for a safe place) Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

2010/1/31, fons@kokkinizita.net :

that means that cdrkit has been renamed to cdrtools ? :-)

Of course, it means that the software has benn renamed or replaced by another one. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it

On Sun, Jan 31, 2010 at 11:55:57PM +0100, Giovanni Scafora wrote:

2010/1/31, fons@kokkinizita.net :

...

that means that cdrkit has been renamed to cdrtools ? :-)

Of course, it means that the software has benn renamed or replaced by another one.

So it can mean two very different things. Which means that the exact background of the question 'Replace kernel-headers by api-headers ?' is unclear, and that the OP had good reason to ask what it meant. Pacman did *not* tell him this was just a rename. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On 01/31/2010 04:24 PM, Giovanni Scafora wrote:

2010/2/1, fons@kokkinizita.net :

...

Pacman did *not* tell him this was just a rename.

pacman just ask him if he wants to replace kernel-headers by api-headers, but it's obvious that software has been renamed or replaced by another one. If you dislike that behaviour, please send a request to pacman-dev ML.

The difference between replaced and renamed is significant though. There's no reason not to replace kernel-headers with linux-api-headers, but there are some other packages (cdrtools vs cdrkit comes to mind) that would give the same message but have a very different effect. Just my 2 cents. -Brendan Long

On 01/02/2010, fons@kokkinizita.net wrote:

On Sun, Jan 31, 2010 at 11:55:57PM +0100, Giovanni Scafora wrote:

...

2010/1/31, fons@kokkinizita.net :

...

that means that cdrkit has been renamed to cdrtools ? :-)

Of course, it means that the software has benn renamed or replaced by another one.

So it can mean two very different things.

Which means that the exact background of the question 'Replace kernel-headers by api-headers ?' is unclear, and that the OP had good reason to ask what it meant. Pacman did *not* tell him this was just a rename.

Oh nono, $replaces isn't used like that. When for instance you have deleted a package and brought in a new one with a different name, often due to a name change (upstream or not), you need to make sure pacman will know and seamlessly "update" to the new package. Sometimes, projects go defunct and forks become active. Asking the user to answer the question resolves one big thing: 1) He will not complain later; he won't be freaked out when he finds one of his packages is missing and/or the system has something he can't recall installing. -- GPG/PGP ID: B42DDCAD

On Mon, 2010-02-01 at 21:08 +1030, Ty John wrote:

On Mon, 1 Feb 2010 15:08:33 +0800 Ray Rashif wrote:

...

On 01/02/2010, fons@kokkinizita.net wrote:

...

On Sun, Jan 31, 2010 at 11:55:57PM +0100, Giovanni Scafora wrote:

...

2010/1/31, fons@kokkinizita.net :

...

that means that cdrkit has been renamed to cdrtools ? :-)

Of course, it means that the software has benn renamed or replaced by another one.

So it can mean two very different things.

Which means that the exact background of the question 'Replace kernel-headers by api-headers ?' is unclear, and that the OP had good reason to ask what it meant. Pacman did *not* tell him this was just a rename.

Oh nono, $replaces isn't used like that. When for instance you have deleted a package and brought in a new one with a different name, often due to a name change (upstream or not), you need to make sure pacman will know and seamlessly "update" to the new package. Sometimes, projects go defunct and forks become active.

Asking the user to answer the question resolves one big thing:

1) He will not complain later; he won't be freaked out when he finds one of his packages is missing and/or the system has something he can't recall installing.

-- GPG/PGP ID: B42DDCAD

I understand what you are saying but it comes back to KISS ideals. The Arch user should know exactly what's happening to their system and not just let everything happen automagically.

Does that preclude informing them? Not everyone is subscribed to [arch-dev-public], and that's probably the only place I heard of the switch from kernel-headers to linux-api-headers before it actually happened, both in [testing] and [core]. I see a distinction between 'knowing what's happening to your system' and 'having to find out the hard way what needs changing'.

On 2 February 2010 05:29, Ty John wrote:

I'm not subscribed to it either and I must admit that I was a bit surprised when I saw the message while updating. I may be wrong but I believe pacman is limited in the way it produces informing messages in that it can only do so in a post install script. Am I right?

I have always stood by the belief that our guys know what they're doing, and nothing has ever happened. I always trust pacman, but in the rare cases where I doubt it, I just check the frontpage. If something goes berserk, you just file a bug report. On 2 February 2010 05:36, Brendan Long wrote:

Sounds like the real problem is pacman's message then. My suggestion: change "package x has been replaced by package y" to "package x has been renamed package y".

It's explained very well in the PKGBUILD manual: replaces (array) An array of packages that this package should replace, and can be used to handle renamed/combined packages. For example, if the j2re package is renamed to jre, this directive allows future upgrades to continue as expected even though the package has moved. Sysupgrade is currently the only pacman operation that utilizes this field, a normal sync will not use its value. Renaming isn't the only case, there can be a set of tools that becomes a "replacement" for one tool, and vice-versa. The final authority on this would be the pacmen, so send in a patch to the pacman list. -- GPG/PGP ID: B42DDCAD

On Mon, Feb 1, 2010 at 10:36 PM, Brendan Long wrote:

Sounds like the real problem is pacman's message then. My suggestion: change "package x has been replaced by package y" to "package x has been renamed package y".

fork/alternative != rename The term 'replace' is more general than a rename. And it's consistent with the implementation : the PKGBUILD variable is called replaces and the db entry is called REPLACES. Are you all suggesting that we introduce renames/RENAMES in PKGBUILD and in the database ? Because that would make things less confusing ? It looks much more confusing to me.