Someone recently experienced a little breakage related to a package rename, and I'm not sure about the best strategy to resolve it.
Upstream finally got around to unbundling a cookie handling library from two unrelated npm packages (tobi and request). We had previously split it off in Fedora before, but needed to rename the package and move it into its final home, so the directory under /usr/lib/node_modules changed. While I shipped an updated nodejs-request along with the new nodejs-cookie-jar package in the same Bodhi update, it's possible to update to nodejs-cookie-jar (which Obsolotes/Provides the old unbundled package) without updating nodejs-request. This will of course will break request since it looks for it under the old, temporary name.
So, should we: 1. provide a compatibility symlink so older versions of nodejs-request aren't broken at all
2. add Conflicts to nodejs-cookie-jar specifiying the older versions of nodejs-request that it will break
3. do nothing; if you install only part of a single bodhi update and it breaks you get to keep both pieces
Both 1 or 2 are ugly in their own way, and 3 might be technically correct but doesn't seem very nice, so I'm not sure how to proceed.
Thanks in advance for suggestions! -T.C.
On 02/05/13 08:38, T.C. Hollingsworth wrote:
So, should we:
provide a compatibility symlink so older versions of nodejs-request aren't broken at all
add Conflicts to nodejs-cookie-jar specifiying the older versions of nodejs-request that it will break
do nothing; if you install only part of a single bodhi update and it breaks you get to keep both pieces
Another option is to say that a rename of a node module is not what the rename guidelines call a "compatible enough replacement" which would mean the new package would not provide the old name, but would still obsolete it.
Any packages that depended on the old name would then need to be rebuilt to depend on the new name and yum would not allow one to be updated without the other.
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/02/2013 06:55 AM, Tom Hughes wrote:
On 02/05/13 08:38, T.C. Hollingsworth wrote:
So, should we: 1. provide a compatibility symlink so older versions of nodejs-request aren't broken at all
- add Conflicts to nodejs-cookie-jar specifiying the older
versions of nodejs-request that it will break
- do nothing; if you install only part of a single bodhi update
and it breaks you get to keep both pieces
FYI, this is not technically permissible. The packaging guidelines require clean upgrade paths. If you need to install multiple pieces of a Bodhi update for things to work, they need to be arranged with Requires/Obsoletes/Conflicts appropriately so that they are pulled in automatically. Anything else is a bug in the packaging.
Another option is to say that a rename of a node module is not what the rename guidelines call a "compatible enough replacement" which would mean the new package would not provide the old name, but would still obsolete it.
That's not necessarily true. If it's a one-to-one replacement (except for the name), then I'd suggest that option 1 is the best plan for the short term, but that we should open Bugzilla tickets against all known packages depending on the old name to update in their next releases.
If just adding a symlink to make it a full replacement is enough to do the job, that's definitely the least impact. No need to force an update until the other package is ready for it.
Any packages that depended on the old name would then need to be rebuilt to depend on the new name and yum would not allow one to be updated without the other.
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I accidentally replied only to the node mailing list, but this is my interpretation of the situation:
On 05/02/2013 07:41 AM, Stephen Gallagher wrote:
On 05/02/2013 06:55 AM, Tom Hughes wrote:
On 02/05/13 08:38, T.C. Hollingsworth wrote:
So, should we: 1. provide a compatibility symlink so older versions of nodejs-request aren't broken at all
- add Conflicts to nodejs-cookie-jar specifiying the older
versions of nodejs-request that it will break
- do nothing; if you install only part of a single bodhi
update and it breaks you get to keep both pieces
FYI, this is not technically permissible. The packaging guidelines require clean upgrade paths. If you need to install multiple pieces of a Bodhi update for things to work, they need to be arranged with Requires/Obsoletes/Conflicts appropriately so that they are pulled in automatically. Anything else is a bug in the packaging.
Another option is to say that a rename of a node module is not what the rename guidelines call a "compatible enough replacement" which would mean the new package would not provide the old name, but would still obsolete it.
That's not necessarily true. If it's a one-to-one replacement (except for the name), then I'd suggest that option 1 is the best plan for the short term, but that we should open Bugzilla tickets against all known packages depending on the old name to update in their next releases.
If just adding a symlink to make it a full replacement is enough to do the job, that's definitely the least impact. No need to force an update until the other package is ready for it.
Any packages that depended on the old name would then need to be rebuilt to depend on the new name and yum would not allow one to be updated without the other.
Tom
_______________________________________________ nodejs mailing list nodejs@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/nodejs
On Thu, May 02, 2013 at 08:36:37AM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I accidentally replied only to the node mailing list, but this is my interpretation of the situation:
On 05/02/2013 07:41 AM, Stephen Gallagher wrote:
On 05/02/2013 06:55 AM, Tom Hughes wrote:
On 02/05/13 08:38, T.C. Hollingsworth wrote:
So, should we: 1. provide a compatibility symlink so older versions of nodejs-request aren't broken at all
- add Conflicts to nodejs-cookie-jar specifiying the older
versions of nodejs-request that it will break
- do nothing; if you install only part of a single bodhi
update and it breaks you get to keep both pieces
FYI, this is not technically permissible. The packaging guidelines require clean upgrade paths. If you need to install multiple pieces of a Bodhi update for things to work, they need to be arranged with Requires/Obsoletes/Conflicts appropriately so that they are pulled in automatically. Anything else is a bug in the packaging.
I'm not sure about this... I seem to recall other cases where the FPC ruled that end users *could* install pieces of an update and get broken systems. The right thing to do was to update all of the pieces instead.
If you could point to some guidelines that imply the opposite it might be that there's some finer grained distinction when it's appropriate and when it's not. Or alternately, someone needs to reopen some tickets saying that the precedent actually is for us to take care of these.
Here's the latest example I could find: https://fedorahosted.org/fpc/ticket/241
and Timestamp 17:47:49 http://meetbot.fedoraproject.org/fedora-meeting-1/2013-02-06/fpc.2013-02-06-...
This is slightly different as it is crossing a release boundary (f17+ updates to f18) but it's similar in nature.
Another option is to say that a rename of a node module is not what the rename guidelines call a "compatible enough replacement" which would mean the new package would not provide the old name, but would still obsolete it.
That's not necessarily true. If it's a one-to-one replacement (except for the name), then I'd suggest that option 1 is the best plan for the short term, but that we should open Bugzilla tickets against all known packages depending on the old name to update in their next releases.
If just adding a symlink to make it a full replacement is enough to do the job, that's definitely the least impact. No need to force an update until the other package is ready for it.
One note here: From the sounds of the original post, we're talking about a very few (just one?) package here and that package has already been updated. If that's true, adding a versioned Requires/Conflict pair or telling people that all the pieces have to be updated seems like the right thing.
-Toshio
nodejs@lists.fedoraproject.org