Hi,
At Mon, 20 May 2013 19:33:43 -0700,
Russ Allbery wrote:
>
> Guillem Jover 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
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 o
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.
>
> Havi
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 serio
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 portabilit
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
> clea
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 regressio
es than dpatch and dbs floating around
in Debian; and I consider it to be a step forward to move this way,
rather than trying to fix each patching script.
regards,
junichi
--
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]
both in the original private
> discussion 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
--
em with the following:
Your proposal met some objections due to the fact that 'source' is an
already widely used keyword; and is in a limbo state although two
developers already seconded it.
AFAICT, no action has been taken after approx two months.
Care to give an update?
regard
> > unpack: some packages unpack the upstream tarball, some do patching
> > patch: some patch the source tree, some generate patch out of it.
> 2. A policy on what target to have for optional unpacking and patching,
> and apply a recommendation that is enforced on etch/etch+1
>
> That should p
atched
source code is the best.
As a transition period, I am evaluating whether it is feasible
to prepare a list of commands required for each package to be
unpacked and patched.
regards,
junichi
--
Junichi Uekawa, Debian Developer
17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
urce.build, source.make
cdbs: pre-build, apply-patches
dpatch: already done, 'patch' target
I'm considering of adding
debian-unpack-upstream/debian-apply-patch
aliases to the above targets.
Would that be feasible?
regards,
junichi
--
Junichi Ueka
> > 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 i
> 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
>
> > 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 li
> Sorry, I did not follow the discussion closely, so I may
> understand this wrong. But how does your proposal solve the
> following situation?
>
> libfoo1 Build-Depends on libssl0.9.6-dev
> libfoo2 Build-Depends on libssl0.9.7-dev
> libbreakseverything Build-Depends on libfoo1-dev an
> 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
> 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' th
> > 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 u
> 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
> aga
> > - 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
> > - 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
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
> > 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 (ja_J
> > 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
> > 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.
> > > | Right now, people are putting whatever random characters they feel like
> > > | in Debian changelogs;
> > >
> > > I think we shouldn't use must just yet, since this will cause a lot of
> > > packages (you know how many?) to be instantly buggy. If you change
> > > the ?must? to ?should?, I
> | 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
> | charact
> (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 recei
> >- 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
> 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 w
system is bootstrapped, everything is in an
unconfigured state. Dpkg doesn't unconfigure 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/
k, and creates a symlink.
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
uld draw the conclusion that only multiple-line 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,
j
and sed.
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]
w
nds* fields to have multiple
lines.
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, e
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
seems to convey much of the information
that I tried 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/
--
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-gui
o fix
> in some cases.
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 Fingerprin
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 Uek
hi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
hought it is even 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
for compilation or
execution (thus, the package must 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
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 exa
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 t
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
> > 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
> > utf8 in the current state does not cover everything we had in other
> > encodings.
>
> utf8 is just a _multibyte_ encoding, not _character_ encoding,
> it can represent whatever character encoding is used in UCS-4
UCS4 is not a satisfac
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 en
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 o
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 a
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
specification
57 matches
Mail list logo
