package, package2, package3 naming-with-version exploit

[Toshio Kuratomi]

On Mar 28, 2013 6:09 PM, "Michael Scherer" <misc at zarb.org> wrote:
>
> Le jeudi 28 mars 2013 à 17:45 +0100, Vít Ondruch a écrit :
>
>
> > If this problem was put first time on the table in 2002,
> > then there already passed 10 years of excuses.
>
> Or that in 10 years, we didn't found a proper solution that was
> sustainable.
>
> > It is interesting to see
> > that our competition can do much more with our technology then we do.
>
> Depend on what you define as "competition" and "our technology".
> While this could be anything, I will assume that you are speaking of
> debian, cause that's the only one that make sense to me.
>
> If I am not wrong, on debian, you can have 1 single source package that
> by magic could generate multiple packages for multiple runtimes ( for
> example, for python ). The issue of having multiple stack remain ( ie, 2
> stack just mean twice the QA, twice more bugs for that packager ), but
> that greatly reduce the burden, that's right.
>
> Now, I do not know ho we could do exept by redoing large part of
> specfile, or by having some macro that generate half of the spec
> automatically. This could be done ( like that's done for debuginfo ),
> and I have seen creative way to mass generate packages, so that exist in
> the wild.
>
> But I am not sure if you are talking of that.
>
>

For debian python specifically, the .py files need to be compatible between
multiple python versions.  They then mark the packages as working on
specific versions of python.  The .py files are installed to a common
directory.  Those files are bye compiled at install time for the python
versions that are installed and marked as compatible.

I do not know how binary extensions are handled.

The debian system doesn't cover multiple versions of the same python
module.  I don't believe they make use of egg installs to do multiple
versions like we do either.

-Toshio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130328/c03562d5/attachment.html>