Hello everyone, I'm not 100% sure this subject belongs in this mailing list, but I can't figure out where else makes better sense.
During the MeeGo conference in Dublin there was some discussion over how to handle shared libraries that are not part of core, and where to place them in the repository. One example that came up went something like this: Developer 1 is building an application that needs libpythonX.Y from upstream that doesn't exist in the core, so they add it to their home space on the community repository and it gets promoted into their finished package. Then developer 2 comes along and also uses libpythonX.Y and does the same thing. Now there is redundancy in the community repository. One possible solution that was suggested was to make libpythonX.Y a separate package in the repository, and since developer 1 was the first to use it they are responsible for it. But if they disappear from the community then we have a stagnant package that others could be relying on. Or a security patch comes along for libpythonX.Y from upstream and developer 1 updates the current libpythonX.Y package and that breaks developer 2's application. Is there a preferred way to handle shared libraries that are not part of core? -Bryce Zimmerman [email protected]
_______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
