I am attempting to build a new package (and maybe this is really a
packaging question) and now have an example that has hit on a rather
long standing confusion of mine. Never having had a good example I was
amiss of being able to properly formulate my lack of understanding (this
is I believe a build-service question).
I am trying to build euca2ools, which is implemented in Python and
requires boto and m2crypto. M2crypto is found in the standard
distribution, thus that does not pose a problem. However, boto
(available as python-boto) is only found in the devel:languages:python
Now, I can certainly make my project dependent on devel:languages:python
and get what I need. That part I understand. However, what happens
if/when I want to submit my work to the project.
How do things end up in the right place, and where would for example
Eucalyptus end up? Further, how would this dependency on
devel:languages:python be resolved? Why would a package that is part of
devel:langauges:ANYTHING not be part of the :standard project?
Come to think of it, I do have another example. A while back I submitted
perlcritic and it's dependent packages to the project and things are in
devel:languages:perl. I made the assumption that from there it would
eventually propagate up the tree and just be available in the
distribution. However, as I just checked it is not. As far as I
understand things, a devel project/repo is subject to have version
changes at pretty much any given time. Thus, I am wondering why packages
would not be in a more static place.
I suppose this is where Contrib might come into play, however, how would
we then separate packages from devel:languages:ANYTHING and put some of
those into :contrib and others into :standard? For example what makes
perl-razor-agents a special package to be part of :standard while a
person wanting perlcritic would have to add devel:languages:perl as a
repo. (Just using perlcritic as an example, not because I feel neglected
but because it is easy for me to illustrate my confusion).
Clarification is appreciated.
Robert Schweikert MAY THE SOURCE BE WITH YOU
Software Engineer Consultant LINUX
Making IT Work As One
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org