[gentoo-dev] 1/2 OT: splitting packages

[gentoo-dev] 1/2 OT: splitting packages

[Enrico Weigelt]

Hi folks,


I know this issue is not actually in the scope of this list, but
maybe some of you might be interested:

Lots of packages have optional parts which (IMHO) should/could be 
their own packages, ie. GUI frontends to console tools (aumix) or 
several language bindings of certain libs/toolkits. 

Those things tend to produce circular dependencies, which can
only be solved with tricks like multiple builds, special useflags
like "build" or "bootstrap". 

For example berkeley db: it written in C and has additional 
bindings for C++ and Java. This produces two kind of problems:

a) for the base system we must take care that it's built w/o them. 
b) if some package needs an special binding, dependencies get tricky
   (AFAIK portage cannot solve feature deps yet)

An clean solution would be having the bindings as separate packages.
Of course, often the upstream is not ready for this yet, and it's
not in the scope of an distro like gentoo to such heavy changes.

But those splits really should be done (IMHO) to make things a lot 
easier. So let's do it - do the split and try to convince the 
upstream to get it in.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 1/2 OT: splitting packages

[Daniel Ostrow]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

On Mon, 2007-05-14 at 23:18 +0200, Enrico Weigelt wrote:
> Hi folks,
> 
> 
> I know this issue is not actually in the scope of this list, but
> maybe some of you might be interested:
> 
> Lots of packages have optional parts which (IMHO) should/could be 
> their own packages, ie. GUI frontends to console tools (aumix) or 
> several language bindings of certain libs/toolkits. 
> 
> Those things tend to produce circular dependencies, which can
> only be solved with tricks like multiple builds, special useflags
> like "build" or "bootstrap". 
> 
> For example berkeley db: it written in C and has additional 
> bindings for C++ and Java. This produces two kind of problems:
> 
> a) for the base system we must take care that it's built w/o them. 
> b) if some package needs an special binding, dependencies get tricky
>    (AFAIK portage cannot solve feature deps yet)
> 
> An clean solution would be having the bindings as separate packages.
> Of course, often the upstream is not ready for this yet, and it's
> not in the scope of an distro like gentoo to such heavy changes.
> 
> But those splits really should be done (IMHO) to make things a lot 
> easier. So let's do it - do the split and try to convince the 
> upstream to get it in.

We release our packages as upstream intends. If they don't split them,
we don't split them, talk to upstream not us. This is what use flags are
for...

--Dan

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] 1/2 OT: splitting packages

[Joshua Jackson]

[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]

Daniel Ostrow wrote:
> On Mon, 2007-05-14 at 23:18 +0200, Enrico Weigelt wrote:
>   
>> Hi folks,
>>
>>
>> I know this issue is not actually in the scope of this list, but
>> maybe some of you might be interested:
>>
>> Lots of packages have optional parts which (IMHO) should/could be 
>> their own packages, ie. GUI frontends to console tools (aumix) or 
>> several language bindings of certain libs/toolkits. 
>>
>> Those things tend to produce circular dependencies, which can
>> only be solved with tricks like multiple builds, special useflags
>> like "build" or "bootstrap". 
>>
>> For example berkeley db: it written in C and has additional 
>> bindings for C++ and Java. This produces two kind of problems:
>>
>> a) for the base system we must take care that it's built w/o them. 
>> b) if some package needs an special binding, dependencies get tricky
>>    (AFAIK portage cannot solve feature deps yet)
>>
>> An clean solution would be having the bindings as separate packages.
>> Of course, often the upstream is not ready for this yet, and it's
>> not in the scope of an distro like gentoo to such heavy changes.
>>
>> But those splits really should be done (IMHO) to make things a lot 
>> easier. So let's do it - do the split and try to convince the 
>> upstream to get it in.
>>     
>
> We release our packages as upstream intends. If they don't split them,
> we don't split them, talk to upstream not us. This is what use flags are
> for...
>
> --Dan
>   
At what point is your sand so fine that you can't identify it as a
grain. In other words...this induces a much larger set of packages that
at least in my opinion would waste a lot of developer time for not a lot
or any benefit, and as mentioned by Daniel we follow upstream and if
they want it as one large package, we'll do it as well.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] 1/2 OT: splitting packages

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

On Mon, 2007-05-14 at 14:25 -0700, Daniel Ostrow wrote:
>
> We release our packages as upstream intends. If they don't split them,
> we don't split them, talk to upstream not us. 

Well that is not always the case. Not to contradict.

We tend to make packages in the Java world that are subsets of a
upstream package. In short it's because many upstreams bundle
dependencies. So we will strip out those dependencies and maintain them
as separate packages. Even though it was not really intended to be such
by upstream.

For example, take dev-java/servletapi ( really tomcat-servlet-api same
sources, soon to be merged with virtual ... ). Many packages ship with a
servlet-api.jar. That jar comes from Tomcat, but is not available as
package on it's own. It's sources were in a separate CVS tree with its
own build system, but as of Tomcat 6. That was merged into unified
source tree and single build system.

Upstream releases a project called Glassfish, that will eventually be
many glassfish-* packages. Although due to the size Glassfish is broken
up but there are not individual sources available per sub-project. JBoss
is very similar, and many packages use JBoss modules. Like
glassfish-jsf-api :) Mighty fun stuff.

We do try to get with upstream were it's feasible. But really much if
this is out of control in the Java world. I believe Maven is an attempt
to reign in some level of control, manageability, and etc. Among other
things.

Granted all this might be unique to Java. Since applications developed
in other languages, don't always have a binary release available. When
one is, rarely do they ship all the libraries in binary format they
need.

But packages do get split up even though upstream does not really
provide for such. I would not recommend doing it unless there is a
reason and need like on the Java front.

Sorry for length.

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]