Handling Multiple Version Scenarios

[Stanislav Ochotnicky]

Quoting T.C. Hollingsworth (2013-06-05 03:56:24)
...
> Now that we have a way to install them, we need a way to tell
> %nodejs_symlink_deps about these special modules.  There are two ways
> I can think of:
> 
> 1.) Make it check %{nodejs_sitelib} at build time for the existence of
> these name at version directories.  This requires that every package that
> have dependencies experiencing this issue to BuildRequire those
> dependencies, but doesn't require keeping track of these centrally as
> with 2.

You mean so that even package that only requires version @2 would need to BR @1?
I am probably misunderstanding something here.

> 
> 2.) Just keep a text file in "nodejs-packaging" with a list of these
> special modules.  That means updating nodejs-packaging and keeping
> track of these special modules, but nothing special for package
> maintainers unless they need to BuildRequire them for %check.  This
> text file would just be a simple newline-separated list of the npm
> names of the affected modules.

We used to have something similar in Java world (maven2-common-poms) which
contained mappings between upstream version and fedora JAR. For reasons that
likely wouldn't affect Node.js this approach was quite bad (and got worse over
time). If you believe the list can be easily updated, pruned and just maintained
then sure, no problem.


> There's also technically 3.) Just ship everything in versioned
> directories so we don't have to worry about it.  But that adds a bunch
> of complexity for a 1% case and requires changing every package, so I
> think that one is a no go.

Nah

> I'm leaning towards 2 because that prevents packagers from having to
> deal with any of this in most cases.  The only one where they'd need
> to be aware of it is for BuildRequires when you need the right version
> of the module, in which case they'd just have to make sure they drag
> in the right version, preferably with something like:
> BuildRequires: npm(uglify-js) < 2
> 
> Note that the right RPM is already brought in properly regardless
> thanks to the "npm(foo)" virtual provides, so that part of the problem
> is already solved.  The RPM name will remain irrelevant, but should
> follow the standard Fedora policy for this regardless (which seems to
> be just appending the major part of the version to the name).

Well...I have one request WRT naming: Always make the latest-greatest version be
without version suffix. When you need to package a new version that breaks stuff
do it like this:

    1. Create new package that is a copy of current version (just append major
       version number to the name)
    2. Update original version to latest/greatest. 

Automatic RPM requires should help here, and you will prevent explosion of
higher and higher version numbers in package names. I've seen it first hand,
it's ugly.

eS

-- 
Stanislav Ochotnicky <sochotnicky at redhat.com>
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com