[Pkg-mono-devel] Packaging of f-spot

[Mirco 'meebey' Bauer]

--=-X90fUmvjuSIve7jcL2bC
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, 2004-04-04 at 21:06, Anthony W. Juckel wrote:
> I've recently finished some preliminary packages for f-spot, but I=20
> wanted to pose some questions to this list before soliciting for a=20
> sponsor on debian-mentors.
>=20
> I'm addressing this message here since I believe my questions focus more=20
> on specific Mono/CLR policies, rather than general Debian packaging=20
> policies.
>=20
> First, f-spot contains a number of c libraries as well as the standard=20
> C# fare, so I'm wondering if it would be a good idea to split the=20
> library up into two packages: f-spot (Architecture: all) and libfspot=20
> (Architecture: any).
I think splitting the package for arch reasons is ok, but not required.
The software would not run without the C libs, so it could be 1 package
with "arch: any".

> Secondly, since there isn't (at least to my=20
> knowledge) a formal Mono/CLR policy yet, I'm wondering what other's=20
> feelings are on packaging Mono binaries.=20
I think you should take a look at the MonoConventions it answers most
questions
You can find the current version at:
http://wiki.debian.net/?MonoConventions

> First, should a wrapper script=20
> be included, or is it preferable to rely upon the bin-misc support that=20
> is installed along with the mono packages?  Second, the default=20
> packaging of f-spot (simply using cdbs with little modification) wants=20
> to put f-spot.exe in /usr/lib/f-spot.  As this is a binary that can be=20
> executed directly (if bin-misc support for mono is enabled), I feel it=20
> should go in /usr/bin.  On the other hand, I've noticed that muine and=20
> monodoc both place .exe files in /usr/lib/{package}, so should I go that=20
> was as well?
See MonoConventions.
Monodoc 0.10 is not MonoConventions conform, 0.11 pre packages are
conform.
The .NET binaries and libs are stored in /usr/share/dotnet/monodoc
In /usr/share/dotnet/lib is a symlink for monodoc.dll to
../monodoc/monodoc.dll _this_ is part of the MonoConventions and its
required to have a .NET lib pool outside of /usr/lib (reasons read the
MonoConventions). the lib/ in the dotnet place is known by the
cli-wrapper (it sets the MONO_PATH evn which is the lib search path),
libs there are found by the mono runtime.
About the binaries, they are located in /usr/share/dotnet/monodoc
there are symlinks in /usr/share/dotnet/bin which goes to ../monodoc
this symlinking is used by the cli-wrapper. Its only required though
when a program should be called directly without wrapper (simple
programs usually). If the upstream ships a shell-wrapper, use it! (and
set if required MONO_PATH yourself)

I think the best is to discuss this on IRC (freenode channel
#debian-mono) because its not clear yet if it stays like this, by now
this systems _works_ and allow other .NET implementations for debian
(like portable dotnet)

>=20
> Finally, I would like to thank the mono packaging team for all their=20
> work.  It is nice to have working and relatively current packages for=20
> mono and its associated libraries in unstable.
>=20
> If anyone would like to download my f-spot packages, they are available=20
> (with some out-of-date mono cruft) at the following apt sources:
>=20
> deb http://www.juckel.net/apt unstable/
> deb-src http://www.juckel.net/apt unstable/
> =20

Mirco


--=-X90fUmvjuSIve7jcL2bC
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBAcGNkzZxMGlBRybkRAtJ8AKCYX31x8/ob65XajQFuov7akWx9XACggmUY
FtH6SLM0kNNUkT+7468OewI=
=D253
-----END PGP SIGNATURE-----

--=-X90fUmvjuSIve7jcL2bC--