[csw-maintainers] Package policy questions

Dagobert Michelsen dam at opencsw.org
Thu Jan 28 21:16:05 CET 2010


Hi Roger,

Am 28.01.2010 um 21:06 schrieb Roger Håkansson:
> I'm packaging a new version of an orphaned package which have a  
> optional dependency package where upstream requires v8plus to build.
> (They write in the README file that their package requires v8plus  
> and will not build on v8)
>
> The question is what to do in cases like this?
> Build the first package without this optional (but for some users  
> wanted) dependency package or build a package which can only be run  
> on machines with v8plus?
> This would mean that we limit our users to machines with UltraSparc  
> CPU's (or newer) which I can't seem to be a big problem (anyone  
> still using old SS10/SS5/SS20's must be pain lovers...) today.

You can build it for sparcv8plus for Solaris 9 and if you want without  
this optional dependency
for sparcv8 for Solaris 8, but this is not mandatory.

> Next issue...
> I think I've read somewhere that we should strive to build all  
> packages with as many options enabled as possible, which seems like  
> a good idea.
> But what about delivering different functionality in the same  
> package for 32/64-bit binaries?
> I've been looking into enabling 64-bit support for ImageMagick, but  
> the dependency chain is starting to get huge and when that list  
> include packages like libbonobo2 it becomes a bit tricky.
> The amount of packages affected by an upgrade of for example  
> libbonobo2 are huge.
> On the other hand, it seems silly to start gar-ifying current  
> versions of some of those packages, which are several years old,  
> just to get 64bit support.
>
> So the question is, what is the preferred solution, skip 64bit until  
> all dependencies have been fixed or build a package with different  
> features enabled for 32 and 64-bit?

The best solution would be to just upgrade to 64 bit now ;-) Kidding  
aside,
it would be cleanest to restrict the features to the ones which are  
available
in both 32 and 64 bit or to skip 64 bit completely and build 64 bit from
ground up. Different features is asking for trouble. Maybe some others
can chime in in a joint-effort to garify and 64 bit enable this stuff?
I like packaging up libraries :-)


Best regards

   -- Dago



More information about the maintainers mailing list