Hi Marguerite, On Wed, Nov 12, 2014 at 03:11:20PM +0800, marguerite wrote:
This is a complaint.
The mess in this repo still happens.
Just saw a bug report filed about npm for Tumbleweed, and fixed another bunch of packages again.
Although most of the mess come from the fragment of nodejs package system, the massive & strict (introduced by nodejs-packaging) dependencies, and the migration from macros.nodejs to nodejs-packagin, there're still things we can take care of:
0. factory auto SRs. If it's accepted, that's okay. But if it's rejected, please at least take some time to see what's wrong and fix it. 1. care. I saw two of the commits that said "use nodejs-packaging to package" but no BuildRequires: nodejs-packaging at all. That shouldn't happen.
This was probably me fault. After I added nodejs-packaging, I used a script to modify the existing packages to use it, and hence use automatic provides/requires. Apparently, this didn't work as intended with a couple of packages. I fixed those issues when I found them, but perhaps the odd one slipped though, so apologies for that.
2. changelog. I saw patches were not mentioned in many of the rejected auto SRs.
I'm (too) guilty of that. I wasn't aware the the patch file name has to appear verbatim in the changelog.
And what's most important: please do not alter the packages directly. because:
0. other maintainers will not receive any notification for that. so no one else will be awared of what's going on, review, and cover for us. 1. it'll not forward to Factory. that's why auto SRs were triggered. Most of the times, auto SRs may be likely to be ignored.
I know there are so many packages in this repo, which makes such suggestion ridiculous, but think about devel:languages:python (it has many more packages I think). Again we can develop a script to do the SRs from branched projects to the devel repo itself.
Ack. I've used scripts to update and check in packages in bulk, but I guess there's no reason why that shouldn't work with submit requests too.
And a few more things:
0. wiki should be updated. because the new nodejs-packaging tool
I'll look into it.
1. Is there any function in nodejs-packaging that can alter the auto detected/parsed dependencies? I remember I saw such things in Fedora. now we use patches, which is hard to track and mostly do a simple same thing.
There is a macro called %nodejs_fixdep, which can be used to alter dependencies. This might be a bit easier to manage than patching package.json actually. It doesn't change the fact though that you have to check manually whether the package actually works with a different version than specified, which really is the time consuming task.
2. Is nodejs so strict about package versions? because I saw many SRs trying to submit old versions of packages, and we did lots of rollback things. How did we verify if a package really can't use a newer version? and what to do/how to do when it needs to have two versions of the same packages in our repo (I saw two situations: one just renames the module to, like, nan-0_8; another uses update-alternatives)? we may need to discuss and develop a policy for that.
As far as I understand, it's actually not node.js that is strict about package version, in fact I think it doesn't care at all. It's really npm. In package.json, the module maintainer can set dependencies to specific version, and it seems a lot of maintainers do exactly that or allow only minor differences in the version number. If the dependency is set to a fairly old version, this can be a problem when another packages requires a newer version. However, it doesn't necessarily mean that it doesn't work with a newer version. When using npm, it doesn't matter because when installing a module, npm simply dumps all required modules in the specified version in a subdirectory of that module. You may end up with the same module installed several times, but this way you don't face version conflicts. At the moment, we have still a good number of broken dependencies in d:l:nodejs. I've spent a while to fix some of them, but it is a bit of a bottomless pit. Some packages I downgraded to satisfy the dependency of other packages. Where there were conflicts, I mostly patched the package requiring the older version to allow a newer one, which seem to work usually. In a couple of cases where accepting a newer version did break, I packaged the required version of the module together with the package. It's perhaps not nice but I couldn't really find a better solution. I don't think update-alternatives is really useful here. It would still not make it possible to use modules that require conflicting versions of the same module at the same time. Node doesn't seem to have support for loading a specific version of a module. You could rename one of the modules, e.g. if you have a package 'foo' that depdens on module 'bar' in version 1.0 and another package 'batz' that depends on 'bar' in version 2.0, you could package bar-1.0 as 'bar1' and patch 'foo' to require 'bar1'. Not exactly ideal though. More generally speaking, handling node.js dependencies is a big pain, but I don't really have an idea what we could do to improve it. Some of the pain probably stems from the fact that the upstream maintainer doesn't really bother to test their stuff with newer versions, and using npm pretty much shields users from running into dependency issues. I don't think we want to go the npm way though and simply package all required modules with each package. We could try to hassle the upstream maintainers to support newer versions of their dependencies, but with hundreds of packages, this seems like never-ending task too. On a related note, I've been working on a python script that parses repository info and shows you packages that have unsatisfied dependencies and also what other packages depend on those, which I found quite helpful while fixing node.js dependencies. I've been meaning to look into more ways of automating tasks to help with node.js packaging, e.g. looking up npm registry to find suitable versions of required modules, fetch tarballs, etc., but haven't managed to do that yet. Any thoughts welcome, of course. Regards Joe -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org