Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > Hi, > > Sven LUTHER: > > Is there a way to handle this so that apt will get the native code > > package if it is available, and resort to the bytecode one on arches not > > supporting the native code compiler ? Some sort of priorities or > > something such ? > > > I'd split the packages in three: > - ocaml (arch-independent, common stuff) > - ocaml-bytecode (ditto, bytecode interpreter) > - ocaml-native (arch-dependent, compiles to native code) Well, it is not so much about the ocaml package, which is already suitably splitted (the bytecode interpreter is in ocaml-base), but about packages built with ocaml. > The latter two provide a common symbol "ocaml-runtime", both require ocaml; > ocaml requires "ocaml-runtime"; either -native can conflict with -bytecode > and vice versa, or you select which you want via the alternatives > mechanism. > > For archs which don't have a native compiler, there's simply no choice. Ok, but then the user will have to specify which version they want installed, and this is what i wanted to solve. That is, i want for the user not to have to worry about the native/bytecode packages, and have the best available installed when he does apt-get install foo. > > BTW, is there a more appropriated list for this kind of question ? > > > Not that I know of. > > > BTW2, if i go with virtual packages, i will most probably run with > > problems on versioned dependencies > > You don't need them here. -bytecode and -native can even be versioned > independently; if a program has a problem with an old -native it can > register a conflict with lower versions of it. Mmm, , mmm, yes i see what you mean. Since the bytecode packages are dependant only on other bytecode packages they can provide a real dependency, the same goes for the native packages. But then the problem is with a package, say bar, which knows nothing about ocaml, and has a versioned dependency on foo, and does not want to have to worry about wheter it is a bytecode or a nativecode version that fullfills this dependency, then it cause problem. Not so easy a solution for this finally, and, altough maybe not right now, we may one day need versioned dependencies for this. (Well, we can always fake them with a virtual package foo-1.2.3 or something such, but it is not the cleanest solution). Anyway, thanks for your response. Friendly, Sven Luther > > -- > Matthias Urlichs | noris network AG | http://smurf.noris.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > I'd split the packages in three: > - ocaml (arch-independent, common stuff) > - ocaml-bytecode (ditto, bytecode interpreter) > - ocaml-native (arch-dependent, compiles to native code) You miss the point: the ocaml package is already split properly, the question arise for application builts with ocaml compilers. Cheers. -- Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy [EMAIL PROTECTED] | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro "I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!" -- G.Romney msg07403/pgp0.pgp Description: PGP signature
Re: Control File
On 2.10.2002 19:28 Uhr, "Simon Richter" <[EMAIL PROTECTED]> wrote:
> The "i" in front of the comma.
>
> Simon
Thanks. Do you have an idea why my Debian still wants to install
apache-common when I make apt-get install php4?
My control file is now (sorry the last one was the old one):
Source: apache-ssl-ywesee
Section: web
Priority: optional
Maintainer: ywesee <[EMAIL PROTECTED]>
Build-Depends: debhelper (>> 3.0.0), libncurses5 (>= 5.2.20020112a-7 ),
libssl0.9.6 (>= 0.9.6c-2.woody.1 ), openssl (>= 0.9.6c-2.woody.1 )
Standards-Version: 3.5.2
Package: apache-ssl-ywesee
Provides: apache, apache-common, apache-ssl
Conflicts: apache
Architecture: any
Depends: ${shlibs:Depends}
Description: apache-ssl by ywesee 3.9.2002
Thanks for your help.
Zeno
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which can be arch: all and arch: any ...
Hi, Stefano Zacchiroli: > On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > > I'd split the packages in three: > > - ocaml (arch-independent, common stuff) > > - ocaml-bytecode (ditto, bytecode interpreter) > > - ocaml-native (arch-dependent, compiles to native code) > > You miss the point: the ocaml package is already split properly, the > question arise for application builts with ocaml compilers. > Oh. *scratches head, re-reads initial email* I did not see that, given this email. Sorry. Anyway, the same three-way split technique can be used for any package using ocaml => take my email and s/ocaml/your-package/g. As for the user's choice ... I did miss the reference to apt-get in the original email, as I was mistakenly of the opinion that it would, like dselect, actually ask which dependent package to install if there's a choice. At the moment the manpage says that apt-get randomly selects a package which fulfills a virtual dependency. (That probably means "it uses the first one it sees in the package list". :-/ ) That shold be fixed; as .deb control files currently don't have a priority field, the first step would probably be to file a bug report^W^W feature request asking for its addition. Or do it yourself and submit a patch... -- Matthias Urlichs | noris network AG | http://smurf.noris.de/ msg07405/pgp0.pgp Description: PGP signature
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 12:23:41PM +0200, Matthias Urlichs wrote: > Hi, > > Stefano Zacchiroli: > > On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > > > I'd split the packages in three: > > > - ocaml (arch-independent, common stuff) > > > - ocaml-bytecode (ditto, bytecode interpreter) > > > - ocaml-native (arch-dependent, compiles to native code) > > > > You miss the point: the ocaml package is already split properly, the > > question arise for application builts with ocaml compilers. > > > Oh. *scratches head, re-reads initial email* > I did not see that, given this email. Sorry. Yes, my fault, i wanted to write it, but must have forgotten or something. > Anyway, the same three-way split technique can be used for any package > using ocaml => take my email and s/ocaml/your-package/g. > > As for the user's choice ... I did miss the reference to apt-get in the > original email, as I was mistakenly of the opinion that it would, like > dselect, actually ask which dependent package to install if there's a > choice. At the moment the manpage says that apt-get randomly selects a > package which fulfills a virtual dependency. (That probably means "it uses > the first one it sees in the package list". :-/ ) That shold be fixed; as > .deb control files currently don't have a priority field, the first step > would probably be to file a bug report^W^W feature request asking for its > addition. Or do it yourself and submit a patch... Yes, i guess that would be nice. Mmm, should i fill a bug report against apt, or is there a better mailing list to discuss these things. In case i submit a patch or something such, should i discuss things first, or just go ahead and implement it ? BTW, do you think apt-get (in its current incarnation) will choose a true package in priority over a virtual one ? that is if i have foo and bar (bar providing foo) and i do a apt-get install foo, will it choose foo over bar, or select randomly ? Alternatively, we could also have the both a foo_1.0-1_all.deb and a foo_1.0-1_i386.deb (for example) in the archive, and have the per arch PAckages file point to the native code one (foo_1.0-1_i386.deb) when it is available, and to the byte code one (foo_1.0-1_all.deb) if it is not. But then this will not allow an user to install the bytecode executable unless he hand installs it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which can be arch: all and arch: any ...
Hi, Sven Luther: > In case i submit a patch or something such, should i discuss things > first, or just go ahead and implement it ? > Probably talk about it first... though frankly I don't see a different way of implementing what you want, and the feature would be nice. (I got bitten by it recently, too -- some packe depended on another package which depended on "some" HTTP server ;-) > BTW, do you think apt-get (in its current incarnation) will choose a > true package in priority over a virtual one ? If my guess is true and it grabs the first one it finds in the package list (I haven't checked the source -- no time :-/ ), that may well be a virtual package. You should probably ask the maintainer(s). -- Matthias Urlichs | noris network AG | http://smurf.noris.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 01:20:34PM +0200, Matthias Urlichs wrote: > Hi, > > Sven Luther: > > In case i submit a patch or something such, should i discuss things > > first, or just go ahead and implement it ? > > > Probably talk about it first... though frankly I don't see a different way > of implementing what you want, and the feature would be nice. (I got > bitten by it recently, too -- some packe depended on another package which > depended on "some" HTTP server ;-) Ok, i will look into it, as time permitt (not that i have much of it right now, but then there is not really all that much urgency in it). I would like to look into versioned virtual packages also at the same time. > > BTW, do you think apt-get (in its current incarnation) will choose a > > true package in priority over a virtual one ? > > If my guess is true and it grabs the first one it finds in the package > list (I haven't checked the source -- no time :-/ ), that may well be a > virtual package. > > You should probably ask the maintainer(s). Ok, will do, Thanks for your help. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which can be arch: all and arch: any ...
On Fre, 2002-10-04 at 10:09, Sven LUTHER wrote: > On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > > > > Sven LUTHER: > > > Is there a way to handle this so that apt will get the native code > > > package if it is available, and resort to the bytecode one on arches not > > > supporting the native code compiler ? Some sort of priorities or > > > something such ? > > > > > I'd split the packages in three: > > - ocaml (arch-independent, common stuff) > > - ocaml-bytecode (ditto, bytecode interpreter) > > - ocaml-native (arch-dependent, compiles to native code) > > Well, it is not so much about the ocaml package, which is already > suitably splitted (the bytecode interpreter is in ocaml-base), but about > packages built with ocaml. > > > The latter two provide a common symbol "ocaml-runtime", both require ocaml; > > ocaml requires "ocaml-runtime"; either -native can conflict with -bytecode > > and vice versa, or you select which you want via the alternatives > > mechanism. > > > > For archs which don't have a native compiler, there's simply no choice. > > Ok, but then the user will have to specify which version they want > installed, and this is what i wanted to solve. That is, i want for the > user not to have to worry about the native/bytecode packages, and have > the best available installed when he does apt-get install foo. Don't provide foo-runtime, but make foo depend on foo-native | foo-bytecode? mono works in a similar way, it depends on mono-jit | mono-interpreter. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 01:44:50PM +0200, Michel D?nzer wrote: > On Fre, 2002-10-04 at 10:09, Sven LUTHER wrote: > > On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > > > > > > Sven LUTHER: > > > > Is there a way to handle this so that apt will get the native code > > > > package if it is available, and resort to the bytecode one on arches not > > > > supporting the native code compiler ? Some sort of priorities or > > > > something such ? > > > > > > > I'd split the packages in three: > > > - ocaml (arch-independent, common stuff) > > > - ocaml-bytecode (ditto, bytecode interpreter) > > > - ocaml-native (arch-dependent, compiles to native code) > > > > Well, it is not so much about the ocaml package, which is already > > suitably splitted (the bytecode interpreter is in ocaml-base), but about > > packages built with ocaml. > > > > > The latter two provide a common symbol "ocaml-runtime", both require ocaml; > > > ocaml requires "ocaml-runtime"; either -native can conflict with -bytecode > > > and vice versa, or you select which you want via the alternatives > > > mechanism. > > > > > > For archs which don't have a native compiler, there's simply no choice. > > > > Ok, but then the user will have to specify which version they want > > installed, and this is what i wanted to solve. That is, i want for the > > user not to have to worry about the native/bytecode packages, and have > > the best available installed when he does apt-get install foo. > > Don't provide foo-runtime, but make foo depend on foo-native | > foo-bytecode? Ah, ok, mmm, but right now this is the dummy package in disguise, isn't it ? > mono works in a similar way, it depends on mono-jit | mono-interpreter. Well, we should be able to do more advanced tricks here, since we can discriminate between native supporting arch at package build time and do some variable substitution tricks. Friendly, Sven Luther > > > -- > Earthling Michel D?nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Control File
Zeno Davatz (2002-10-04 11:13:59 +0200) : > On 2.10.2002 19:28 Uhr, "Simon Richter" <[EMAIL PROTECTED]> wrote: > >> The "i" in front of the comma. >> >> Simon > Thanks. Do you have an idea why my Debian still wants to install > apache-common when I make apt-get install php4? Maybe because php4 depends on a specific version of apache-common. You can't do versioned Provides: (yet), so apt uses one that is known to be the appropriate version. Roland. -- Roland Mas Death *was* hereditary. You got it from your ancestors. -- in Hogfather (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which can be arch: all and arch: any ...
Sven LUTHER wrote: > Since the bytecode executables are arch independent, i think it would be > nice to build them arch: all, since this would mean, apart from smaller > sized packages, also that we don't have 12+ version of the same thing in > the archive (well, at least we can spare all the arches which do not > support native code compilers). > > But then, on arches supporting the native code compiler, we want to > build the app as native code, since this will result in faster > executables. Well if I were you I would avoid the route of splitting off a bunch of -bytecode and -native packages and simply make it arch any and build natice packages on arches where I could, and bytecode packages elsewhere. It uses up a bit of archive space, but is no worse than any compiled program. Trying to save a snidgeon of archive space just because you can here is a kind of false optimization, as you are introducing a lot of unnecessary complexity, both for yourself and for the user in the process of doing so. If these packages are 20 or 100 mb in size, it might be worth trying to optimize for space, but if they are fairly normal in size, it's probably more important to package them in a comprehensible and simple manner. If you really wanted to solve this one right, you could think about implementing Marcus Brinkman's idea that lets packages depend on their architecture(s). That's nice because it solves the general problem you are running into: That of arch "all" packages that are really only useful on a subset of architectures. -- see shy jo msg07412/pgp0.pgp Description: PGP signature
Re: packages which can be arch: all and arch: any ...
En réponse à Joey Hess <[EMAIL PROTECTED]>: > Sven LUTHER wrote: > > Since the bytecode executables are arch independent, i think it would > be > > nice to build them arch: all, since this would mean, apart from > smaller > > sized packages, also that we don't have 12+ version of the same thing > in > > the archive (well, at least we can spare all the arches which do not > > support native code compilers). > > > > But then, on arches supporting the native code compiler, we want to > > build the app as native code, since this will result in faster > > executables. > > Well if I were you I would avoid the route of splitting off a bunch of > -bytecode and -native packages and simply make it arch any and build > natice packages on arches where I could, and bytecode packages > elsewhere. It uses up a bit of archive space, but is no worse than any > compiled program. Trying to save a snidgeon of archive space just > because you can here is a kind of false optimization, as you are > introducing a lot of unnecessary complexity, both for yourself and for > the user in the process of doing so. If these packages are 20 or 100 > mb > in size, it might be worth trying to optimize for space, but if they > are > fairly normal in size, it's probably more important to package them in > a > comprehensible and simple manner. This is exactly what I think. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for sponsor
also sprach Roger Leigh <[EMAIL PROTECTED]> [2002.10.03.0013 +0200]: > Please could someone sponsor an upload of IJS? Please give me exact information what this does. I'd be happy to sponsor you if I know more and if I know about the general topic that this library deals with. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck the web site you seek cannot be located but endless others exist. msg07414/pgp0.pgp Description: PGP signature
Re: Request for sponsor
On Fri, Oct 04, 2002 at 06:17:32PM +0200, martin f krafft wrote: > also sprach Roger Leigh <[EMAIL PROTECTED]> [2002.10.03.0013 +0200]: > > Please could someone sponsor an upload of IJS? > > Please give me exact information what this does. I'd be happy to > sponsor you if I know more and if I know about the general topic that > this library deals with. In case you don't mind, I'm about upload IJS later today. If you want to take over, go ahead. cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depends/Depends wierdness
This one time, at band camp, Michel Dänzer said:
> On Don, 2002-10-03 at 20:09, Stephen Gran wrote:
> >
> > In my control file, I just use ${shlibs:Depends} in the Depends: field.
> > After building (in a Woody chroot, thanks to pbuilder - great tool!) I
> > get a Depends: that looks like this:
> >
> > Depends: kdelibs3 (>= 4:2.2.2-1), libc6 (>= 2.2.4-4), libfam0,
> > libjpeg62, libpng2(>=1.0.12), libqt2 (>= 3:2.3.1-1),
> > libstdc++2.10-glibc2.2 (>= 1:2.95.4-0.010810), xlibs (>> 4.1.0), zlib1g
> > (>= 1:1.1.4)
> >
> > But:
> > steve@gashuffer:~$ for i in `ldd /usr/bin/kcdlabel | cut -f3 -d\ ` ; do
> > dpkg -S $i ; done | sort | cut -f1 -d':' | uniq
> > kdelibs3
> > libc6
> > libfam0
> > libfreetype6
> > libjpeg62
> > liblcms
> > libmng1
> > libpng2
> > libqt2
> > libstdc++2.10-glibc2.2
> > xlibs
> > zlib1g
> >
> > There's 3 more library packages that aren't found by dpkg-shlibdeps. Am
> > I misinterpreting here, and I should in fact put these missing packages
> > in manually, or am I somehow building poorly, and that is causing the
> > discrepancy in the output?
>
> I think ldd also shows indirectly linked libraries, i.e. those linked to
> libraries the app links to. Those don't generate a dependency, and
> neither should they. If the app uses one of those directly, it should
> link to it directly as well, then it will generate a dependency.
>
> Now I hope this explains something and doesn't confuse. :)
No, that was actually quite helpful. I am chasing this around because
someone who wrote me offlist suggested that it actually depended on more
libraries than I had listed. I checked with objdump, and it agrees with
the generated field (as I expected - that's what dpkg-shlibdeps uses,
right?). I cannot seem to set up an environment without the missing
libraries, as that would remove tons of other kde stuff, and prevent me
from running the program (in addition to hosing many of my users'
desktops), so I'm going to believe objdump over ldd at this point.
Now, is anyone interested in sponsoring it? 8^)
You can take a look at http://www.lobefin.net/~steve/debian/
Thanks all who responded,
Steve
--
Sweet April showers do spring May flowers.
-- Thomas Tusser
msg07416/pgp0.pgp
Description: PGP signature
Re: Request for sponsor
also sprach Michael Banck <[EMAIL PROTECTED]> [2002.10.04.2051 +0200]: > In case you don't mind, I'm about upload IJS later today. If you want to > take over, go ahead. All yours. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck like disneyland, (micro$oft) windows had been designed with a mouse in mind. msg07417/pgp0.pgp Description: PGP signature
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 11:25:55AM -0400, Joey Hess wrote: > Sven LUTHER wrote: > > Since the bytecode executables are arch independent, i think it would be > > nice to build them arch: all, since this would mean, apart from smaller > > sized packages, also that we don't have 12+ version of the same thing in > > the archive (well, at least we can spare all the arches which do not > > support native code compilers). > > > > But then, on arches supporting the native code compiler, we want to > > build the app as native code, since this will result in faster > > executables. > > Well if I were you I would avoid the route of splitting off a bunch of > -bytecode and -native packages and simply make it arch any and build > natice packages on arches where I could, and bytecode packages > elsewhere. It uses up a bit of archive space, but is no worse than any > compiled program. Trying to save a snidgeon of archive space just > because you can here is a kind of false optimization, as you are > introducing a lot of unnecessary complexity, both for yourself and for > the user in the process of doing so. If these packages are 20 or 100 mb Well, what about the coq for example, which is 7 MB package (on i386, so maybe it is bigger for other arches) and 20MB installed. There may be other packages as well. For package who don't really need to be that quick, we build only the bytecode anyway (ledit or hevea for example). There is also the buildd resources, especially on the slower arches. I guess it takes much time to build coq on m68k for example, while i could have built the exact same executable on my i386 box. > in size, it might be worth trying to optimize for space, but if they are > fairly normal in size, it's probably more important to package them in a > comprehensible and simple manner. But if we can package them in a transparent way for the user, and without much effort on the developpers side, it is worth the effort, is it not ? > If you really wanted to solve this one right, you could think about > implementing Marcus Brinkman's idea that lets packages depend on their > architecture(s). That's nice because it solves the general problem you > are running into: That of arch "all" packages that are really only > useful on a subset of architectures. Mmm, do you have a pointer to were i can look more at this ideas. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Pinging Scott Dier, or looking for keysigners in Minneapolis
Scott, are you still out there? On 6-17 you said you could sign my key, and I've tried to get in touch with you twice since then. Otherwise, I'm still looking for an existing developer to sign my key, in the Minneapolis area, near the UMN campus. I don't have a car and can't drive anyway, so it would be a major pain for me to get anywhere else. TIA. -- - Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Request for sponsor
martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Roger Leigh <[EMAIL PROTECTED]> [2002.10.03.0013 +0200]:
> > Please could someone sponsor an upload of IJS?
>
> Please give me exact information what this does. I'd be happy to
> sponsor you if I know more and if I know about the general topic that
> this library deals with.
Thanks for the offer, but Michael Banck has now uploaded it. FYI, the
package descriptions are:
Package: libijs-0.34-dev
Section: devel
Architecture: any
Depends: libc6-dev, libijs-0.34
Provides: libijs-dev
Conflicts: libijs-dev
Description: IJS raster image transport protocol: development files
IJS is, first and foremost, a protocol for transmission of raster page
images. This snapshot provides a reference implementation of the
protocol, the design of which is still in flux. When the protocol
specification is published, it will be authoritative. Applications
should feel free to link against the library provided in this package,
adapt that code for their own needs, or roll a completely new
implementation.
.
IJS is a client-server protocol, used to write ghostscript drivers. The
drivers are separate programs. The client and server communicate via pipes,
though shared memory may be used additionally in the future. Currently IJS is
used by the hpijs and ijsgimpprint drivers.
.
Code for both the client- and server-side is included in the library. This
package provides a static library, development headers and documentation.
Package: libijs-0.34
Section: libs
Architecture: any
Depends: ${shlibs:Depends}
Description: IJS raster image transport protocol: shared library
[snip identical part]
Code for both the client- and server-side is included in the library. This
package provides the shared library.
Regards,
Roger
--
Roger Leigh
"Liberty and Livelihood" - Support the Countryside Alliance
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which can be arch: all and arch: any ...
Sven LUTHER wrote: > Well, what about the coq for example, which is 7 MB package (on i386, so > maybe it is bigger for other arches) and 20MB installed. I guess it's on the line. > There is also the buildd resources, especially on the slower > arches. I guess it takes much time to build coq on m68k for example, > while i could have built the exact same executable on my i386 box. So build all the bytecode architectures on your i386 box. :-) It actually is doable. > > If you really wanted to solve this one right, you could think about > > implementing Marcus Brinkman's idea that lets packages depend on their > > architecture(s). That's nice because it solves the general problem you > > are running into: That of arch "all" packages that are really only > > useful on a subset of architectures. > > Mmm, do you have a pointer to were i can look more at this ideas. I haven't been able to dig it up easily. -- see shy jo msg07421/pgp0.pgp Description: PGP signature
Re: Build-Depends/Depends wierdness
Stephen Gran <[EMAIL PROTECTED]> immo vero scripsit: > No, that was actually quite helpful. I am chasing this around because > someone who wrote me offlist suggested that it actually depended on more > libraries than I had listed. I checked with objdump, and it agrees with > the generated field (as I expected - that's what dpkg-shlibdeps uses, > right?). I cannot seem to set up an environment without the missing > libraries, as that would remove tons of other kde stuff, and prevent me > from running the program (in addition to hosing many of my users' > desktops), so I'm going to believe objdump over ldd at this point. You can try pbuilder. It is designed to do such jobs. 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] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 07:38:05PM -0400, Joey Hess wrote: > Sven LUTHER wrote: > > Well, what about the coq for example, which is 7 MB package (on i386, so > > maybe it is bigger for other arches) and 20MB installed. > > I guess it's on the line. I thought so, But sure, this is the biggest project using ocaml. More may come in the future though. I think the rate of ocaml programs being made available is increasing, at least i see that from the announcement that are being made, and many of them are not yet packaged. > > There is also the buildd resources, especially on the slower > > arches. I guess it takes much time to build coq on m68k for example, > > while i could have built the exact same executable on my i386 box. > > So build all the bytecode architectures on your i386 box. :-) It > actually is doable. Mmm, and upload 5 versions of it ? I now have ADSL, but i guess people with slow modems will be not at all happy about proposing a solution like that. BTW, I don't only propose this for me, but there are a few maintainers which package ocaml stuff and which are more directly concerned than me. I am just writing a policy proposal for all things related to ocaml, so each package related to it will be packaged with a uniform way, without too much surprise for our users. > > > If you really wanted to solve this one right, you could think about > > > implementing Marcus Brinkman's idea that lets packages depend on their > > > architecture(s). That's nice because it solves the general problem you > > > are running into: That of arch "all" packages that are really only > > > useful on a subset of architectures. > > > > Mmm, do you have a pointer to were i can look more at this ideas. > > I haven't been able to dig it up easily. Ok, i will look at it. Thanks for your help, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Control File
On 2.10.2002 19:28 Uhr, "Simon Richter" <[EMAIL PROTECTED]> wrote:
> The "i" in front of the comma.
>
> Simon
Thanks. Do you have an idea why my Debian still wants to install
apache-common when I make apt-get install php4?
My control file is now:
Source: apache-ssl-ywesee
Section: web
Priority: optional
Maintainer: ywesee <[EMAIL PROTECTED]>
Build-Depends: debhelper (>> 3.0.0), libncurses5 (>= 5.2.20020112a-7 ),
libssl0.9.6 (>= 0.9.6c-2.woody.1 ), openssl (>= 0.9.6c-2.woody.1 )
Standards-Version: 3.5.2
Package: apache-ssl-ywesee
Replaces: apache, apache-common, apache-ssl
Architecture: any
Depends: ${shlibs:Depends}
Description: apache-ssl by ywesee 3.9.2002
Thanks for your help.
Zeno
packages which can be arch: all and arch: any ...
Hello, ... Well, this will be a complex question, and the subject is not all that speaking, i apologize for it... I maintain the ocaml package, which is a language which can produce bytecode executables to be run in a virtual machine (as java does) or native code executables (well, the source is converted to asm and then assembled by gcc) on a limited range of arches (alpha, arm, i386, ia64, powerpc and sparc). Since the bytecode executables are arch independent, i think it would be nice to build them arch: all, since this would mean, apart from smaller sized packages, also that we don't have 12+ version of the same thing in the archive (well, at least we can spare all the arches which do not support native code compilers). But then, on arches supporting the native code compiler, we want to build the app as native code, since this will result in faster executables. That said, my first idea was, for a source package foo, to have a binary package foo containing the bytecode executable and being arch: all, and a binary package foo-native for the 6 arches who support it (which would replace, provide and all that is needed the foo package). The problem is that for the native supporting arches, both the arch: all and the native code package is available, one being called foo, the other providing foo. It is my guess that if a user does an apt-get install foo, he will get the bytecode package, even if the native code is available. Is there a way to handle this so that apt will get the native code package if it is available, and resort to the bytecode one on arches not supporting the native code compiler ? Some sort of priorities or something such ? BTW, is there a more appropriated list for this kind of question ? BTW2, if i go with virtual packages, i will most probably run with problems on versioned dependencies, do someone know what is the problem with that, if there is a fundamental flaw with doing them, or if it is only the manpower to implement them which is at fault. Friendly, Sven Luther
Re: packages which can be arch: all and arch: any ...
Hi, Sven LUTHER: > Is there a way to handle this so that apt will get the native code > package if it is available, and resort to the bytecode one on arches not > supporting the native code compiler ? Some sort of priorities or > something such ? > I'd split the packages in three: - ocaml (arch-independent, common stuff) - ocaml-bytecode (ditto, bytecode interpreter) - ocaml-native (arch-dependent, compiles to native code) The latter two provide a common symbol "ocaml-runtime", both require ocaml; ocaml requires "ocaml-runtime"; either -native can conflict with -bytecode and vice versa, or you select which you want via the alternatives mechanism. For archs which don't have a native compiler, there's simply no choice. > BTW, is there a more appropriated list for this kind of question ? > Not that I know of. > BTW2, if i go with virtual packages, i will most probably run with > problems on versioned dependencies You don't need them here. -bytecode and -native can even be versioned independently; if a program has a problem with an old -native it can register a conflict with lower versions of it. -- Matthias Urlichs | noris network AG | http://smurf.noris.de/
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > Hi, > > Sven LUTHER: > > Is there a way to handle this so that apt will get the native code > > package if it is available, and resort to the bytecode one on arches not > > supporting the native code compiler ? Some sort of priorities or > > something such ? > > > I'd split the packages in three: > - ocaml (arch-independent, common stuff) > - ocaml-bytecode (ditto, bytecode interpreter) > - ocaml-native (arch-dependent, compiles to native code) Well, it is not so much about the ocaml package, which is already suitably splitted (the bytecode interpreter is in ocaml-base), but about packages built with ocaml. > The latter two provide a common symbol "ocaml-runtime", both require ocaml; > ocaml requires "ocaml-runtime"; either -native can conflict with -bytecode > and vice versa, or you select which you want via the alternatives > mechanism. > > For archs which don't have a native compiler, there's simply no choice. Ok, but then the user will have to specify which version they want installed, and this is what i wanted to solve. That is, i want for the user not to have to worry about the native/bytecode packages, and have the best available installed when he does apt-get install foo. > > BTW, is there a more appropriated list for this kind of question ? > > > Not that I know of. > > > BTW2, if i go with virtual packages, i will most probably run with > > problems on versioned dependencies > > You don't need them here. -bytecode and -native can even be versioned > independently; if a program has a problem with an old -native it can > register a conflict with lower versions of it. Mmm, , mmm, yes i see what you mean. Since the bytecode packages are dependant only on other bytecode packages they can provide a real dependency, the same goes for the native packages. But then the problem is with a package, say bar, which knows nothing about ocaml, and has a versioned dependency on foo, and does not want to have to worry about wheter it is a bytecode or a nativecode version that fullfills this dependency, then it cause problem. Not so easy a solution for this finally, and, altough maybe not right now, we may one day need versioned dependencies for this. (Well, we can always fake them with a virtual package foo-1.2.3 or something such, but it is not the cleanest solution). Anyway, thanks for your response. Friendly, Sven Luther > > -- > Matthias Urlichs | noris network AG | http://smurf.noris.de/
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > I'd split the packages in three: > - ocaml (arch-independent, common stuff) > - ocaml-bytecode (ditto, bytecode interpreter) > - ocaml-native (arch-dependent, compiles to native code) You miss the point: the ocaml package is already split properly, the question arise for application builts with ocaml compilers. Cheers. -- Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy [EMAIL PROTECTED] | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro "I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!" -- G.Romney pgpHY0VplSTlX.pgp Description: PGP signature
Re: Control File
On 2.10.2002 19:28 Uhr, "Simon Richter" <[EMAIL PROTECTED]> wrote:
> The "i" in front of the comma.
>
> Simon
Thanks. Do you have an idea why my Debian still wants to install
apache-common when I make apt-get install php4?
My control file is now (sorry the last one was the old one):
Source: apache-ssl-ywesee
Section: web
Priority: optional
Maintainer: ywesee <[EMAIL PROTECTED]>
Build-Depends: debhelper (>> 3.0.0), libncurses5 (>= 5.2.20020112a-7 ),
libssl0.9.6 (>= 0.9.6c-2.woody.1 ), openssl (>= 0.9.6c-2.woody.1 )
Standards-Version: 3.5.2
Package: apache-ssl-ywesee
Provides: apache, apache-common, apache-ssl
Conflicts: apache
Architecture: any
Depends: ${shlibs:Depends}
Description: apache-ssl by ywesee 3.9.2002
Thanks for your help.
Zeno
Re: packages which can be arch: all and arch: any ...
Hi, Stefano Zacchiroli: > On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > > I'd split the packages in three: > > - ocaml (arch-independent, common stuff) > > - ocaml-bytecode (ditto, bytecode interpreter) > > - ocaml-native (arch-dependent, compiles to native code) > > You miss the point: the ocaml package is already split properly, the > question arise for application builts with ocaml compilers. > Oh. *scratches head, re-reads initial email* I did not see that, given this email. Sorry. Anyway, the same three-way split technique can be used for any package using ocaml => take my email and s/ocaml/your-package/g. As for the user's choice ... I did miss the reference to apt-get in the original email, as I was mistakenly of the opinion that it would, like dselect, actually ask which dependent package to install if there's a choice. At the moment the manpage says that apt-get randomly selects a package which fulfills a virtual dependency. (That probably means "it uses the first one it sees in the package list". :-/ ) That shold be fixed; as .deb control files currently don't have a priority field, the first step would probably be to file a bug report^W^W feature request asking for its addition. Or do it yourself and submit a patch... -- Matthias Urlichs | noris network AG | http://smurf.noris.de/ pgpa3MIGXMVNR.pgp Description: PGP signature
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 12:23:41PM +0200, Matthias Urlichs wrote: > Hi, > > Stefano Zacchiroli: > > On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > > > I'd split the packages in three: > > > - ocaml (arch-independent, common stuff) > > > - ocaml-bytecode (ditto, bytecode interpreter) > > > - ocaml-native (arch-dependent, compiles to native code) > > > > You miss the point: the ocaml package is already split properly, the > > question arise for application builts with ocaml compilers. > > > Oh. *scratches head, re-reads initial email* > I did not see that, given this email. Sorry. Yes, my fault, i wanted to write it, but must have forgotten or something. > Anyway, the same three-way split technique can be used for any package > using ocaml => take my email and s/ocaml/your-package/g. > > As for the user's choice ... I did miss the reference to apt-get in the > original email, as I was mistakenly of the opinion that it would, like > dselect, actually ask which dependent package to install if there's a > choice. At the moment the manpage says that apt-get randomly selects a > package which fulfills a virtual dependency. (That probably means "it uses > the first one it sees in the package list". :-/ ) That shold be fixed; as > .deb control files currently don't have a priority field, the first step > would probably be to file a bug report^W^W feature request asking for its > addition. Or do it yourself and submit a patch... Yes, i guess that would be nice. Mmm, should i fill a bug report against apt, or is there a better mailing list to discuss these things. In case i submit a patch or something such, should i discuss things first, or just go ahead and implement it ? BTW, do you think apt-get (in its current incarnation) will choose a true package in priority over a virtual one ? that is if i have foo and bar (bar providing foo) and i do a apt-get install foo, will it choose foo over bar, or select randomly ? Alternatively, we could also have the both a foo_1.0-1_all.deb and a foo_1.0-1_i386.deb (for example) in the archive, and have the per arch PAckages file point to the native code one (foo_1.0-1_i386.deb) when it is available, and to the byte code one (foo_1.0-1_all.deb) if it is not. But then this will not allow an user to install the bytecode executable unless he hand installs it. Friendly, Sven Luther
Re: packages which can be arch: all and arch: any ...
Hi, Sven Luther: > In case i submit a patch or something such, should i discuss things > first, or just go ahead and implement it ? > Probably talk about it first... though frankly I don't see a different way of implementing what you want, and the feature would be nice. (I got bitten by it recently, too -- some packe depended on another package which depended on "some" HTTP server ;-) > BTW, do you think apt-get (in its current incarnation) will choose a > true package in priority over a virtual one ? If my guess is true and it grabs the first one it finds in the package list (I haven't checked the source -- no time :-/ ), that may well be a virtual package. You should probably ask the maintainer(s). -- Matthias Urlichs | noris network AG | http://smurf.noris.de/
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 01:20:34PM +0200, Matthias Urlichs wrote: > Hi, > > Sven Luther: > > In case i submit a patch or something such, should i discuss things > > first, or just go ahead and implement it ? > > > Probably talk about it first... though frankly I don't see a different way > of implementing what you want, and the feature would be nice. (I got > bitten by it recently, too -- some packe depended on another package which > depended on "some" HTTP server ;-) Ok, i will look into it, as time permitt (not that i have much of it right now, but then there is not really all that much urgency in it). I would like to look into versioned virtual packages also at the same time. > > BTW, do you think apt-get (in its current incarnation) will choose a > > true package in priority over a virtual one ? > > If my guess is true and it grabs the first one it finds in the package > list (I haven't checked the source -- no time :-/ ), that may well be a > virtual package. > > You should probably ask the maintainer(s). Ok, will do, Thanks for your help. Friendly, Sven Luther
Re: packages which can be arch: all and arch: any ...
On Fre, 2002-10-04 at 10:09, Sven LUTHER wrote: > On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > > > > Sven LUTHER: > > > Is there a way to handle this so that apt will get the native code > > > package if it is available, and resort to the bytecode one on arches not > > > supporting the native code compiler ? Some sort of priorities or > > > something such ? > > > > > I'd split the packages in three: > > - ocaml (arch-independent, common stuff) > > - ocaml-bytecode (ditto, bytecode interpreter) > > - ocaml-native (arch-dependent, compiles to native code) > > Well, it is not so much about the ocaml package, which is already > suitably splitted (the bytecode interpreter is in ocaml-base), but about > packages built with ocaml. > > > The latter two provide a common symbol "ocaml-runtime", both require ocaml; > > ocaml requires "ocaml-runtime"; either -native can conflict with -bytecode > > and vice versa, or you select which you want via the alternatives > > mechanism. > > > > For archs which don't have a native compiler, there's simply no choice. > > Ok, but then the user will have to specify which version they want > installed, and this is what i wanted to solve. That is, i want for the > user not to have to worry about the native/bytecode packages, and have > the best available installed when he does apt-get install foo. Don't provide foo-runtime, but make foo depend on foo-native | foo-bytecode? mono works in a similar way, it depends on mono-jit | mono-interpreter. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 01:44:50PM +0200, Michel D?nzer wrote: > On Fre, 2002-10-04 at 10:09, Sven LUTHER wrote: > > On Fri, Oct 04, 2002 at 09:12:52AM +0200, Matthias Urlichs wrote: > > > > > > Sven LUTHER: > > > > Is there a way to handle this so that apt will get the native code > > > > package if it is available, and resort to the bytecode one on arches not > > > > supporting the native code compiler ? Some sort of priorities or > > > > something such ? > > > > > > > I'd split the packages in three: > > > - ocaml (arch-independent, common stuff) > > > - ocaml-bytecode (ditto, bytecode interpreter) > > > - ocaml-native (arch-dependent, compiles to native code) > > > > Well, it is not so much about the ocaml package, which is already > > suitably splitted (the bytecode interpreter is in ocaml-base), but about > > packages built with ocaml. > > > > > The latter two provide a common symbol "ocaml-runtime", both require > > > ocaml; > > > ocaml requires "ocaml-runtime"; either -native can conflict with -bytecode > > > and vice versa, or you select which you want via the alternatives > > > mechanism. > > > > > > For archs which don't have a native compiler, there's simply no choice. > > > > Ok, but then the user will have to specify which version they want > > installed, and this is what i wanted to solve. That is, i want for the > > user not to have to worry about the native/bytecode packages, and have > > the best available installed when he does apt-get install foo. > > Don't provide foo-runtime, but make foo depend on foo-native | > foo-bytecode? Ah, ok, mmm, but right now this is the dummy package in disguise, isn't it ? > mono works in a similar way, it depends on mono-jit | mono-interpreter. Well, we should be able to do more advanced tricks here, since we can discriminate between native supporting arch at package build time and do some variable substitution tricks. Friendly, Sven Luther > > > -- > Earthling Michel D?nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > >
Re: Control File
Zeno Davatz (2002-10-04 11:13:59 +0200) : > On 2.10.2002 19:28 Uhr, "Simon Richter" <[EMAIL PROTECTED]> wrote: > >> The "i" in front of the comma. >> >> Simon > Thanks. Do you have an idea why my Debian still wants to install > apache-common when I make apt-get install php4? Maybe because php4 depends on a specific version of apache-common. You can't do versioned Provides: (yet), so apt uses one that is known to be the appropriate version. Roland. -- Roland Mas Death *was* hereditary. You got it from your ancestors. -- in Hogfather (Terry Pratchett)
Re: packages which can be arch: all and arch: any ...
Sven LUTHER wrote: > Since the bytecode executables are arch independent, i think it would be > nice to build them arch: all, since this would mean, apart from smaller > sized packages, also that we don't have 12+ version of the same thing in > the archive (well, at least we can spare all the arches which do not > support native code compilers). > > But then, on arches supporting the native code compiler, we want to > build the app as native code, since this will result in faster > executables. Well if I were you I would avoid the route of splitting off a bunch of -bytecode and -native packages and simply make it arch any and build natice packages on arches where I could, and bytecode packages elsewhere. It uses up a bit of archive space, but is no worse than any compiled program. Trying to save a snidgeon of archive space just because you can here is a kind of false optimization, as you are introducing a lot of unnecessary complexity, both for yourself and for the user in the process of doing so. If these packages are 20 or 100 mb in size, it might be worth trying to optimize for space, but if they are fairly normal in size, it's probably more important to package them in a comprehensible and simple manner. If you really wanted to solve this one right, you could think about implementing Marcus Brinkman's idea that lets packages depend on their architecture(s). That's nice because it solves the general problem you are running into: That of arch "all" packages that are really only useful on a subset of architectures. -- see shy jo pgpzPBRDuktau.pgp Description: PGP signature
Re: packages which can be arch: all and arch: any ...
En réponse à Joey Hess <[EMAIL PROTECTED]>: > Sven LUTHER wrote: > > Since the bytecode executables are arch independent, i think it would > be > > nice to build them arch: all, since this would mean, apart from > smaller > > sized packages, also that we don't have 12+ version of the same thing > in > > the archive (well, at least we can spare all the arches which do not > > support native code compilers). > > > > But then, on arches supporting the native code compiler, we want to > > build the app as native code, since this will result in faster > > executables. > > Well if I were you I would avoid the route of splitting off a bunch of > -bytecode and -native packages and simply make it arch any and build > natice packages on arches where I could, and bytecode packages > elsewhere. It uses up a bit of archive space, but is no worse than any > compiled program. Trying to save a snidgeon of archive space just > because you can here is a kind of false optimization, as you are > introducing a lot of unnecessary complexity, both for yourself and for > the user in the process of doing so. If these packages are 20 or 100 > mb > in size, it might be worth trying to optimize for space, but if they > are > fairly normal in size, it's probably more important to package them in > a > comprehensible and simple manner. This is exactly what I think. Cheers, -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org
Re: Request for sponsor
also sprach Roger Leigh <[EMAIL PROTECTED]> [2002.10.03.0013 +0200]: > Please could someone sponsor an upload of IJS? Please give me exact information what this does. I'd be happy to sponsor you if I know more and if I know about the general topic that this library deals with. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] the web site you seek cannot be located but endless others exist. pgpkr8i9eXlMB.pgp Description: PGP signature
Re: Request for sponsor
On Fri, Oct 04, 2002 at 06:17:32PM +0200, martin f krafft wrote: > also sprach Roger Leigh <[EMAIL PROTECTED]> [2002.10.03.0013 +0200]: > > Please could someone sponsor an upload of IJS? > > Please give me exact information what this does. I'd be happy to > sponsor you if I know more and if I know about the general topic that > this library deals with. In case you don't mind, I'm about upload IJS later today. If you want to take over, go ahead. cheers, Michael
Re: Build-Depends/Depends wierdness
This one time, at band camp, Michel Dänzer said:
> On Don, 2002-10-03 at 20:09, Stephen Gran wrote:
> >
> > In my control file, I just use ${shlibs:Depends} in the Depends: field.
> > After building (in a Woody chroot, thanks to pbuilder - great tool!) I
> > get a Depends: that looks like this:
> >
> > Depends: kdelibs3 (>= 4:2.2.2-1), libc6 (>= 2.2.4-4), libfam0,
> > libjpeg62, libpng2(>=1.0.12), libqt2 (>= 3:2.3.1-1),
> > libstdc++2.10-glibc2.2 (>= 1:2.95.4-0.010810), xlibs (>> 4.1.0), zlib1g
> > (>= 1:1.1.4)
> >
> > But:
> > [EMAIL PROTECTED]:~$ for i in `ldd /usr/bin/kcdlabel | cut -f3 -d\ ` ; do
> > dpkg -S $i ; done | sort | cut -f1 -d':' | uniq
> > kdelibs3
> > libc6
> > libfam0
> > libfreetype6
> > libjpeg62
> > liblcms
> > libmng1
> > libpng2
> > libqt2
> > libstdc++2.10-glibc2.2
> > xlibs
> > zlib1g
> >
> > There's 3 more library packages that aren't found by dpkg-shlibdeps. Am
> > I misinterpreting here, and I should in fact put these missing packages
> > in manually, or am I somehow building poorly, and that is causing the
> > discrepancy in the output?
>
> I think ldd also shows indirectly linked libraries, i.e. those linked to
> libraries the app links to. Those don't generate a dependency, and
> neither should they. If the app uses one of those directly, it should
> link to it directly as well, then it will generate a dependency.
>
> Now I hope this explains something and doesn't confuse. :)
No, that was actually quite helpful. I am chasing this around because
someone who wrote me offlist suggested that it actually depended on more
libraries than I had listed. I checked with objdump, and it agrees with
the generated field (as I expected - that's what dpkg-shlibdeps uses,
right?). I cannot seem to set up an environment without the missing
libraries, as that would remove tons of other kde stuff, and prevent me
from running the program (in addition to hosing many of my users'
desktops), so I'm going to believe objdump over ldd at this point.
Now, is anyone interested in sponsoring it? 8^)
You can take a look at http://www.lobefin.net/~steve/debian/
Thanks all who responded,
Steve
--
Sweet April showers do spring May flowers.
-- Thomas Tusser
pgpNtIfqlNcmt.pgp
Description: PGP signature
Re: Request for sponsor
also sprach Michael Banck <[EMAIL PROTECTED]> [2002.10.04.2051 +0200]: > In case you don't mind, I'm about upload IJS later today. If you want to > take over, go ahead. All yours. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] like disneyland, (micro$oft) windows had been designed with a mouse in mind. pgpjEUnhj6lNV.pgp Description: PGP signature
Re: packages which can be arch: all and arch: any ...
On Fri, Oct 04, 2002 at 11:25:55AM -0400, Joey Hess wrote: > Sven LUTHER wrote: > > Since the bytecode executables are arch independent, i think it would be > > nice to build them arch: all, since this would mean, apart from smaller > > sized packages, also that we don't have 12+ version of the same thing in > > the archive (well, at least we can spare all the arches which do not > > support native code compilers). > > > > But then, on arches supporting the native code compiler, we want to > > build the app as native code, since this will result in faster > > executables. > > Well if I were you I would avoid the route of splitting off a bunch of > -bytecode and -native packages and simply make it arch any and build > natice packages on arches where I could, and bytecode packages > elsewhere. It uses up a bit of archive space, but is no worse than any > compiled program. Trying to save a snidgeon of archive space just > because you can here is a kind of false optimization, as you are > introducing a lot of unnecessary complexity, both for yourself and for > the user in the process of doing so. If these packages are 20 or 100 mb Well, what about the coq for example, which is 7 MB package (on i386, so maybe it is bigger for other arches) and 20MB installed. There may be other packages as well. For package who don't really need to be that quick, we build only the bytecode anyway (ledit or hevea for example). There is also the buildd resources, especially on the slower arches. I guess it takes much time to build coq on m68k for example, while i could have built the exact same executable on my i386 box. > in size, it might be worth trying to optimize for space, but if they are > fairly normal in size, it's probably more important to package them in a > comprehensible and simple manner. But if we can package them in a transparent way for the user, and without much effort on the developpers side, it is worth the effort, is it not ? > If you really wanted to solve this one right, you could think about > implementing Marcus Brinkman's idea that lets packages depend on their > architecture(s). That's nice because it solves the general problem you > are running into: That of arch "all" packages that are really only > useful on a subset of architectures. Mmm, do you have a pointer to were i can look more at this ideas. Friendly, Sven Luther
Pinging Scott Dier, or looking for keysigners in Minneapolis
Scott, are you still out there? On 6-17 you said you could sign my key, and I've tried to get in touch with you twice since then. Otherwise, I'm still looking for an existing developer to sign my key, in the Minneapolis area, near the UMN campus. I don't have a car and can't drive anyway, so it would be a major pain for me to get anywhere else. TIA. -- - Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Request for sponsor
martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Roger Leigh <[EMAIL PROTECTED]> [2002.10.03.0013 +0200]:
> > Please could someone sponsor an upload of IJS?
>
> Please give me exact information what this does. I'd be happy to
> sponsor you if I know more and if I know about the general topic that
> this library deals with.
Thanks for the offer, but Michael Banck has now uploaded it. FYI, the
package descriptions are:
Package: libijs-0.34-dev
Section: devel
Architecture: any
Depends: libc6-dev, libijs-0.34
Provides: libijs-dev
Conflicts: libijs-dev
Description: IJS raster image transport protocol: development files
IJS is, first and foremost, a protocol for transmission of raster page
images. This snapshot provides a reference implementation of the
protocol, the design of which is still in flux. When the protocol
specification is published, it will be authoritative. Applications
should feel free to link against the library provided in this package,
adapt that code for their own needs, or roll a completely new
implementation.
.
IJS is a client-server protocol, used to write ghostscript drivers. The
drivers are separate programs. The client and server communicate via pipes,
though shared memory may be used additionally in the future. Currently IJS is
used by the hpijs and ijsgimpprint drivers.
.
Code for both the client- and server-side is included in the library. This
package provides a static library, development headers and documentation.
Package: libijs-0.34
Section: libs
Architecture: any
Depends: ${shlibs:Depends}
Description: IJS raster image transport protocol: shared library
[snip identical part]
Code for both the client- and server-side is included in the library. This
package provides the shared library.
Regards,
Roger
--
Roger Leigh
"Liberty and Livelihood" - Support the Countryside Alliance
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers
Re: packages which can be arch: all and arch: any ...
Sven LUTHER wrote: > Well, what about the coq for example, which is 7 MB package (on i386, so > maybe it is bigger for other arches) and 20MB installed. I guess it's on the line. > There is also the buildd resources, especially on the slower > arches. I guess it takes much time to build coq on m68k for example, > while i could have built the exact same executable on my i386 box. So build all the bytecode architectures on your i386 box. :-) It actually is doable. > > If you really wanted to solve this one right, you could think about > > implementing Marcus Brinkman's idea that lets packages depend on their > > architecture(s). That's nice because it solves the general problem you > > are running into: That of arch "all" packages that are really only > > useful on a subset of architectures. > > Mmm, do you have a pointer to were i can look more at this ideas. I haven't been able to dig it up easily. -- see shy jo pgppPFTwy9fAl.pgp Description: PGP signature
Re: Build-Depends/Depends wierdness
Stephen Gran <[EMAIL PROTECTED]> immo vero scripsit: > No, that was actually quite helpful. I am chasing this around because > someone who wrote me offlist suggested that it actually depended on more > libraries than I had listed. I checked with objdump, and it agrees with > the generated field (as I expected - that's what dpkg-shlibdeps uses, > right?). I cannot seem to set up an environment without the missing > libraries, as that would remove tons of other kde stuff, and prevent me > from running the program (in addition to hosing many of my users' > desktops), so I'm going to believe objdump over ldd at this point. You can try pbuilder. It is designed to do such jobs. 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/
