On Tue, Aug 12, 2008 at 12:16:03PM -0400, Jack Howarth wrote:
> Peter,
>    I don't know if I would say the scons scripts are broken. The
> relax package is designed (by default) to be untarred in some
> directory (say /usr/local/relax-1.3.0) and then 'scons' called
> to compile the c code for relax followed by 'scons install'
> to install relax in /usr/local/relax, create a symlink in
> /usr/local/bin and compile the python scripts in relax. All I did
> was adjust the scons scripts not automatically compile the python
> scripts and to install in the fink installation directory
> rather than in the %p. The postinstall script for relax then just
> reverts the changes to the scons scripts so that %p rather than %i
> used. My goal in the packaging was to keep the patch changes
> as limited as possible so that future relax releases would be
> unlikely to break the patch. I think you guys are making this
> way more complex than it needs to be. Have you actually looked
> at relax-py.patch and relax-py.info in unstable?

Yes, and I already fixed some pretty bad breakage so far (you were
assuming "python" in path was fink's and that it was the same python
version as the variant).

If relax-pyXX is really a clean python-varianted package, it doesn't
need to conflicts/replaces its other variants. If it's a package that
uses python internally but doesn't supply python modules that other
packages use, it shouldn't be varianted as if it's a public python
module.

But overall, you're still looking at "how to use scons according to
upstream plans, pretending PostInst is the actual install phase" not
"how to create a good package".

Having a package "create" package files that aren't in the .deb is
rude to users who want to find out "what package supplies this
file?"...  if I were doing a security audit, I'd be pretty worried by
having files in the fink hierarchy that weren't part of any fink
package! Why delete bin/relax and then create it later?

There are lots of ways to do things "well" and packagers who have
solved these types of problems before in ways that create a good user
experience. Please don't reinvent broken wheels or just do "what
upstream does" purely because that's what they do.

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel

Reply via email to