diff options
author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
---|---|---|
committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/attachments/20130306/2813cb80 | |
parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
download | archives-master.tar archives-master.tar.gz archives-master.tar.bz2 archives-master.tar.xz archives-master.zip |
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20130306/2813cb80')
-rw-r--r-- | zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment-0001.html | 37 | ||||
-rw-r--r-- | zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment.html | 37 |
2 files changed, 74 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment-0001.html new file mode 100644 index 000000000..74ed32880 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment-0001.html @@ -0,0 +1,37 @@ +<br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 8:44 AM, Guillaume Rousse <span dir="ltr"><<a href="mailto:guillomovitch@gmail.com" target="_blank">guillomovitch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> + +Le 06/03/2013 00:50, Reinout van Schouwen a écrit :<div><div class="h5"><br> +<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +Hi all,<br> +<br> +The Dutch tax service makes life difficult for (64-bit) Mageia users<br> +because the tax filing program expects the i586 versions of libxext6 and<br> +libsm6 to be around.<br> +<br> +The tax service claim on their web site that Ubuntu 12.x and Linux Mint<br> +13 are supported. Could it be that they have these libraries<br> +preinstalled on 64 bit platforms?<br> +<br> +Would it be possible to provide some kind of stub package that downloads<br> +the program with the required dependencies, like Arch does? (<br> +<a href="https://aur.archlinux.org/packages/belastingdienst-ib2012/" target="_blank">https://aur.archlinux.org/<u></u>packages/belastingdienst-<u></u>ib2012/</a> )<br> +</blockquote></div></div> +Most binary-only i586 programs expects additional 32 bits libraires dependencies: skype, for instance. On a pure 64 bits systems, these libraries won't be installed, and they won't even be available directly, as long as 32 bits additional package sources are not configured...<br> + +</blockquote><div><br></div><div>I think we configure the 32 bits media by default</div><div>Having a 32 bits package installing this app and having the proper dependencies would make sense</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> + + +<br> +I'm effraid than endlessly adding 32bits dependencies on our 64 bits packages, such as we did with pulseaudio for skype case, or adding 'stub' packages here, won't scale indefinitly to match every piece of softwares we can't distribute ourselves. First, they are exceptions to our 'self-containment' package sources policy... Second, dependencies won't adress the package source configuration issue.<br> + + +<br> +So, what about adressing end users intelligence, and document all those issues on a central 'compatibility' page on our wiki, instead of relying on such kind of hacks ?<span class="HOEnZb"><font color="#888888"><br> + + +<br> +-- <br> +BOFH excuse #155:<br> +<br> +Dumb terminal<br> +</font></span></blockquote></div><br> diff --git a/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment.html b/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment.html new file mode 100644 index 000000000..74ed32880 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130306/2813cb80/attachment.html @@ -0,0 +1,37 @@ +<br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 8:44 AM, Guillaume Rousse <span dir="ltr"><<a href="mailto:guillomovitch@gmail.com" target="_blank">guillomovitch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> + +Le 06/03/2013 00:50, Reinout van Schouwen a écrit :<div><div class="h5"><br> +<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +Hi all,<br> +<br> +The Dutch tax service makes life difficult for (64-bit) Mageia users<br> +because the tax filing program expects the i586 versions of libxext6 and<br> +libsm6 to be around.<br> +<br> +The tax service claim on their web site that Ubuntu 12.x and Linux Mint<br> +13 are supported. Could it be that they have these libraries<br> +preinstalled on 64 bit platforms?<br> +<br> +Would it be possible to provide some kind of stub package that downloads<br> +the program with the required dependencies, like Arch does? (<br> +<a href="https://aur.archlinux.org/packages/belastingdienst-ib2012/" target="_blank">https://aur.archlinux.org/<u></u>packages/belastingdienst-<u></u>ib2012/</a> )<br> +</blockquote></div></div> +Most binary-only i586 programs expects additional 32 bits libraires dependencies: skype, for instance. On a pure 64 bits systems, these libraries won't be installed, and they won't even be available directly, as long as 32 bits additional package sources are not configured...<br> + +</blockquote><div><br></div><div>I think we configure the 32 bits media by default</div><div>Having a 32 bits package installing this app and having the proper dependencies would make sense</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> + + +<br> +I'm effraid than endlessly adding 32bits dependencies on our 64 bits packages, such as we did with pulseaudio for skype case, or adding 'stub' packages here, won't scale indefinitly to match every piece of softwares we can't distribute ourselves. First, they are exceptions to our 'self-containment' package sources policy... Second, dependencies won't adress the package source configuration issue.<br> + + +<br> +So, what about adressing end users intelligence, and document all those issues on a central 'compatibility' page on our wiki, instead of relying on such kind of hacks ?<span class="HOEnZb"><font color="#888888"><br> + + +<br> +-- <br> +BOFH excuse #155:<br> +<br> +Dumb terminal<br> +</font></span></blockquote></div><br> |