Hi,
At Mon, 20 May 2013 19:33:43 -0700,
Russ Allbery wrote:
Guillem Jover guil...@debian.org writes:
Perhaps, but I think we just lack better documentation and advice when
it comes to shared library handling in general.
There was an attempt by Junichi Uekawa (CCed) some time ago [L
Hi,
(If patched is in use by one of the major patch systems today and I just
forgot about it, please let me know.)
Part of the original thread was picking something that currently wasn't
used so that we could be assured that we weren't changing the semantics of
something already out
Hi,
Policy section 10.2 currently states that packages installing libraries
into private directories should edit /etc/ld.so.conf directly. There
now seems to be an /etc/ld.so.conf.d directory into which packages can
drop files that are included from the main /etc/ld.so.conf file.
Having a
Hi,
Sorry to say, but I disagree. Surely compatibility issues
should be covered in the Debian Policy manual. Esp. looking
at Ubuntu compatibility is (or will become) highly important.
Debian should prioritize compatibility within Debian itself; and focus
on it. If it's broken that's a serious
Hi,
Maybe I haven't seen it, but IMHO the Debian policy should
be more precise about _which_ soversion to use for shared
libraries.
Can we use our own soversion, ignoring other Linux distros
and the rest of the world? Is upstream always right?
Of course this affects portability on
Hi,
I don't want to be discouraging, but are we sure that translating our
internal documents like the policy manual is a very good idea ?
There are two important points: (1) A good translation can
help non-native speakers to understand some points that is not quite
clear and (2)
hi,
It seems to me that the right way for packages to offer their tests in
the source tree. As I say in the wiki page:
I'm interested in QA of packages, especially those that I
actually develop and maintain. Currently Debian does not
provide an easy-enough infrastructure for easy regression
between Scheme implementation maintainers and on these
lists.
By the way, can you point out some example code which
will actually be ran with those virtual packages ?
It would be nice to have some kind of testsuite.
regards,
junichi
--
Junichi Uekawa, Debian Developer http
--
Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
not restart the services on package upgrades. Broken ones still calling
/etc/init.d/whatever directly will, but that's a bug: report it whenever you
find one of these packages.
Packages using debhelper appear to still use /etc/init.d directly.
They will not use /etc/init.d when
dlopening with RTDL_GLOBAL, where there is an option to
dlopen with RTDL_LOCAL.
hmm... how does that behaves when the conflict is two or more libs down the
chain from the PoV of the stuff being dlopened?
I have thought that symbols are resolved locally, as to allow
modules to be
Looks good to me. It can't go into policy yet, though. Not enough
machinery, and we really need to have all core libs converted and working to
whatever policy we choose before we propose it.
Yes, and I consider libpkg-guide to be a place to
start documenting things before policy is changed
dlopening with RTDL_GLOBAL, where there is an option to
dlopen with RTDL_LOCAL.
hmm... how does that behaves when the conflict is two or more libs down the
chain from the PoV of the stuff being dlopened?
I have thought that symbols are resolved locally, as to allow
modules to be linked
At time X libssl0.9.6-dev is in Debian.
At time X ssh is built against libssl0.9.6-dev.
At time Y libssl0.9.7-dev is uploaded to Debian.
At time Y libldap2 is built against libssl0.9.7-dev.
At time Z a user installs libssl0.9.6, libssl0.9.7, ssh, libldap2
and libpam-ldap, all of which are
- Conflict between library versions
- Wouldn't allow valid setups where the versions aren't linked into
the same process
- Lots of packages would end up uninstallable for certain library
upgrades
Those two reasons make it obvious we should not do that I think.
- Conflict between library -dev packages, and -dev packages to
depend on correct version of other -dev packages.
- Would allow valid setups
- Packages may become FTBFS, but when they are fixed,
packages work.
see libpkg-guide for fuller story.
And I think it is
ssh-krb5 was built a while ago using libssl0.9.6. libldap2 will shortly
be uploaded and links against libssl0.9.7. ssh-krb5 ends up linked
against libldap2 though libpam-ldap and the PAM modules (or libnss-ldap
and the nsswitch.conf, either way). The ssh-krb5 process ends up linked
against
Consider libpng2/3 problem, and see if it possible to
still possible to cause problem while following libpkg-guide.
Yes, and I think it's frightening that you advocate staticly linking
things in your libpkg-guide and the fact that you even wrote one while
apparently not entirely
What about it would avoid libssl0.9.6 problems? Nothing I saw would
solve the problems of multiple versions of a library ending up linked
into the same process except the symbol versioning portion, which is
what I'm advocating here but you seem to be against while offering
'solutions' that
Although I thought static libs might be useless for a second,
I remembered that I actually do use static libs...
It's not about disks so much as bandwidth. Disk may be cheap, but
bandwidth isn't, at lesast not universally. I've also no idea who
would want or need static libraries in this
Not all of the statements made in that thread are not quite true,
and I seem to remember seeing some hacks done by Ukai-san on that
respect, for UTF-8.
Hmmm...could you elaborate?
I think our man-db and groff have been hacked in two ways:
1) to special-case japanese locale
But the current situation is *already* broken! For example, for a
Chinese person, an ISO-8859-1 system simply cannot encode, nor display,
their language. I am aware that for people entrenched in legacy
charsets like ISO-8859-1, the transition may introduce
incompatibilities. But
Sorry, we have to start somewhere. Unicode is the way of the future,
and if we wait until every vendor of some random terminal updates it
with support for UTF-8, we will never start.
I don't disagree that we should move to Unicode. I disagree that such
a move must inherently remove
| Right now, people are putting whatever random characters they feel like
| in Debian changelogs; they might be encoded in ISO-8859-1, BIG5,
| ISO-8859-2, ISO-2022-JP, or who knows what. This does come up in the
| real world; I use apt-listchanges, and I fairly often see broken
| characters
- It would in theory let software like doc-base dynamically generate
the documentation formats the user desires after installation.
The more I think about this idea of building on install, though, the
more I think it's completely insane. At least until the XML/SGML
builders out there
(BTW does anyone know offhand of a good reference for what's supposed
to happen when you end up with conflicting shared-lib sub-depends?
I.e. libfoo - libbar - libbaz1
- libbax - libbaz2
so that libfoo is indirectly linked against two versions of libbaz?
I've received
That makes sense (variation on #4). How about this text? (I'll
formalise it as a proposal/diff when people have had a chance to
comment)
When a new virtual package is needed, the maintainers involved should
decide between themselves on what names should be used, and a
definition of what
,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
it as such.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
On 19 Sep 2002 17:02:24 -0600
Georg Lehner [EMAIL PROTECTED] wrote:
It is my opinion, that all sh-scripts involved in the standard system
should be posix-sh compatible _and_ that the selection of the /bin/sh
symlink should be realized by the alternative-mecanism instead of
diverting.
I think
field is
Description:, and other fields are disallowed.
There may be tools that we don't know that depend on this
behavior. All tools I know of work, but at least awk/sed/grep
don't, in their simplest forms.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http
] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On Mon, 13 May 2002 07:47:35 +0100
Julian Gilbey [EMAIL PROTECTED] wrote:
Sounds better than my patch, and it seems to convey much of the information
that I tried to convey.
Although sometimes this is not correct, for example if multiple
co-operating packages use the same /usr/lib/
to convey.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
from the same
source tree you may lump them all together into a single
shared library package, provided that you change all of
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg
.
Would it be too bad to include whole dpkg -l output ?
It sometimes may help, especially when libraries start
diverting other libraries etc.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059
Package: debian-policy
Version: 3.5.6.0
Policy states that there is a
Build-Depends field in the control file.
However, many packages use Build-depends.
Most tools ignore the case, it might be helpful to clarify this point in
the policy.
--
[EMAIL PROTECTED] : Junichi Uekawa http
not fix it?
That's a problem on its own.
If it is a free software with sources, it is very unlikely that
it cannot be fixed.
Debian has a very good reputation for keeping old versions of
software, and maintaining it over its life limit :P
regards,
junichi
--
[EMAIL PROTECTED] : Junichi
better to remove /usr entirely.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
not declare a Depends,
Recommends, or Build-Depends relationship on a non-_main_
package),
* must not be so buggy that we refuse to support them, and
* must meet all policy requirements presented in this manual.
--
[EMAIL PROTECTED] : Junichi Uekawa http
Raul Miller [EMAIL PROTECTED] immo vero scripsit
On Wed, Jun 06, 2001 at 08:42:28PM +0900, Junichi Uekawa wrote:
UCS4 is not a satisfactory encoding for our needs, unfortunately.
JIS is not comlpete either, but UCS4 is less.
Could you provide some examples of characters encoded in JIS
Radovan Garabik [EMAIL PROTECTED] immo vero scripsit
well... it seems to be a stateful (sp?) encoding scheme...
while this is OKish for text documents and mail messages,
it is definitely not suitable for file names and similar
That statement is not quite correct. It is not unsuitable for
Radovan Garabik [EMAIL PROTECTED] immo vero scripsit
TELL ME HOW IN THE HELL I CAN WRITE A MAIL WITH WORDS FROM
HUNGARIAN, SLOVAK, RUSSIAN AN JAPANESE TOGETHER
Unicode was not panacea, but it solved most of the problems,
although setting it up was not painless.
This has nothing to do
Radovan Garabik [EMAIL PROTECTED] immo vero scripsit
I would not go against making programs utf-8-aware,
but I don't think that changing all the documentation to utf-8
is going too far.
not yet - it will be just recommendation so far
Nice to hear that.
regards,
junichi
--
Radovan Garabik [EMAIL PROTECTED] immo vero scripsit
On Fri, Jun 01, 2001 at 02:09:28PM +0200, Josip Rodin wrote:
On Fri, Jun 01, 2001 at 01:58:37PM +0200, Radovan Garabik wrote:
...
There has to be an end to this.
Yes, but I doubt we are going to be able to put an end to it.
At
Anand Kumria [EMAIL PROTECTED] cum veritate scripsit:
I would like to propose ladspa-host and ladspa-plugin as names of virtual
packages which
ladspa-host: application capable of using ladspa-plugins to process audio
data
ladspa-plugin: provides plug-in libraries in accordance to
Anand Kumria [EMAIL PROTECTED] cum veritate scripsit:
Well, to elaborate a bit more, a ladspa plugin package would not depend on
any shared library, or sometimes libc/libm. But that would not be a very
informative dependency information. Such a package would usually be
useful only when
Santiago Vila [EMAIL PROTECTED] cum veritate scripsit:
Who cares about changelogs if there is no requirement that they tell
the truth?
I've always thought changelogs were necessary because GPL wants this :
2. You may modify your copy or copies of the Program or any portion
of it, thus
Package: debian-policy
Severity: wishlist
I would like to propose ladspa-host and ladspa-plugin as names of virtual
packages which
ladspa-host: application capable of using ladspa-plugins to process audio data
ladspa-plugin: provides plug-in libraries in accordance to the ladspa
50 matches
Mail list logo
