"harry up for freeze" strangeness
Freeze is coming and I want to be sure that all packages of mine will be included in woody release. So I looked at http://ftp-master.debian.org/testing/index.html and links from here to know which package of mine are currently in testing and which aren't. Most packages of mine are not listed in the update_excuses.html page so I guess that all packages not listed here are in testing with no problem at all, am I wrong? (Note that currently I have no open bug). The only package that is listed as out of date is lablgtkmathview, it is out of date on arm and sparc architecture. On arm the last built was tried Wed 17 Oct and failed to unmet dependencies on lablgtk package. Currently the problem of lablgtk is solved but the built was not retried ... How can I manage to retry the built? Again: on sparc the built was not tried at all, but last upload was a lot of time ago, how can I manage to try the built? Last one, in the page unstable_probs.html are listed minidom and gtkmathview packages (both are mines): * Binaries from gtkmathview 0.2.7-1 cannot be installed: * libgtkmathview-bin(sh) * libgtkmathview-dev(sh) * libgtkmathview0(sh) * Binaries from minidom 0.1.2-2 cannot be installed: * libminidom-dev(sh) * libminidom0(sh) What does this means? What I have to do to solve the problems? Tnx mentors. Cheers! -- Stefano "Zack" Zacchiroli <[EMAIL PROTECTED]> ICQ# 33538863 Home Page: http://www.cs.unibo.it/~zacchiro Undergraduate student of Computer Science @ University of Bologna, Italy - Information wants to be Open - pgpVnsJT7dVQZ.pgp Description: PGP signature
Playing with dpkg's mind
Hi, I want to move the various interactive fiction games from their own packages to management by a common "installer" package. See #107245 and related bugs. The installer package will own the various games; any transition packages must end up not containing the respective game file so that the transition package can be safely removed without purging the game file as well. I came up with various solutions and can't decide on either one. Someone give me a clue? In following I call the old version of the package OP, the transition package TP, and the game file I want to keep GF. 1. If TP is installed over OP it fiddles with /var/lib/dpkg/info/OP.list so that GF is no longer in there. This is done in TP's preinst. The subsequent removal of OP should not remove GF. 2. Ship GF with TP, and in TP's postinst configure stage, remove GF from TP.list. If the admin remove TP later on, GF should stay. 3. Include GF in TP in a different location as GF' (like /usr/share/games/zcode-transition). In the postinst, hardlink GF' to its proper place GF. Removal of TP will delete GF', but GF will stay behind. 4. Same as 3, but copy instead of hardlink. 5. Include nothing in TP, and let the installer download GF. The dis/advantages as I see them: 1 saves the most bandwidth, while 2-4 include the exact same GF that was already installed. 5 does not include it in the deb but you have to fetch it from another location still. 1 and 2 are dirty as they mess with dpkg's mind. 4 wastes space while TP is installed (by holding a dupe of GF on the disk). 3 may not work (I'm not positive how dpkg fares with multiply-linked files). 1 did not work in my tests. It seems that dpkg reads in the .list file before the preinst is executed, so that script is not able to decieve dpkg. 5 while being cleanest, inconveniences users without a convenient/cheap net connection. Such a user may be a bit upset at installing TP from a CD, only to discover that it removed a file that he now has to fetch anew from the Internet. Im leaning towards 2. -- Robbe signature.ng Description: PGP signature
Re: Shared libraries dependancies
[EMAIL PROTECTED] writes: > marvin:/usr/lib# ldd libgdome.so.0.6.9 > libc.so.6 => /lib/libc.so.6 (0x40041000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) That's because libgdome.so.0.6.9 was wrongly compiled ... > > Now, discussing with another developer he noted that when libgdome.so is > compiled, the switches -shared and -lxml2 are not present, and this could > be the cause for the missing dependancies. Exactly. On platforms supporting inter-library dependencies (like ELF/Linux), shared libs should "link in" other shared libs they depend on. This will make the ldd output correct. As a rule of thumb, "gcc libgdome.so.0.6.9" should only gripe about a missing "main", no other missing symbols, unless you've forgotten some dependencies. > What should gdome2 do? Something like gcc -shared -o libgdome.so.0.6.9 -Wl,-soname,$(SONAME) -lxml2 $(OBJS) should do the trick. If upstream wants to be portable, they should look into libtool. -- Robbe signature.ng Description: PGP signature
Re: apt-howto's package
Gustavo Noronha Silva <[EMAIL PROTECTED]> writes: > > Unless you see definitive value in having an easy way to install all > > translations (I don't), you should state in the description that the > > package is only there for the purpose of upgrading, can be safely > > uninstalled, and will go away somewhen in the future. Like, say, > > perl-5.005. > that wouldn't be needed as the package has never been in stable, am > I wrong? I don't know if it is mandated, but providing a nice upgrade path to people running unstable or testing will raise your karma. You should probably prevent your transition package from going into stable, though. -- Robbe signature.ng Description: PGP signature
Re: Playing with dpkg's mind
On 07-Nov-2001 Robert Bihlmeyer wrote: > Hi, > > I want to move the various interactive fiction games from their own > packages to management by a common "installer" package. See #107245 > and related bugs. The installer package will own the various games; > any transition packages must end up not containing the respective game > file so that the transition package can be safely removed without > purging the game file as well. > > I came up with various solutions and can't decide on either one. > Someone give me a clue? > I am a little confused. In the bug you state your intention is to simply offer a downloader that will retrieve the games. So why all of the dpkg confusion here? Seems mucking with dpkg's files is a BAD idea. Truth is any solution is going to lead to a little user confusion. I see debconf in your future. Why not do this a simple way? Upload packages of the same name without the games in it. Then the installer package can handle it from there. Although I wonder why we even need an installer package since downloading these amounts to browsing an ftp archive and grabbing one or two files. Perhaps we should just remove the packages and forget about it. Not all problems need an engineering solution.
Re: Playing with dpkg's mind
> > I want to move the various interactive fiction games from their own > packages to management by a common "installer" package. See #107245 > and related bugs. The installer package will own the various games; > any transition packages must end up not containing the respective game > file so that the transition package can be safely removed without > purging the game file as well. I actually rather like having IF games controlled by dpkg -- just like I like having all the other sofwtware and even documentation I use under it. The only issues I see are: 1. There are a *lot* of IF games! 2. They are small individually. Both can be aided by having groups of games when possible -- e.g., one pack for each IF competition. Also, both would be alleviated if the "games" category had a subcategory for IF. At any rate, we already have a system for managing installed programs. Is there really no way to use it? -Lex
Re: Playing with dpkg's mind
> > At any rate, we already have a system for managing installed programs. > Is there really no way to use it? > and more importantly, why skip ours and use a special purpose one.
Re: Playing with dpkg's mind
[...] > I actually rather like having IF games controlled by dpkg -- just like I > like having all the other sofwtware and even documentation I use under > it. The only issues I see are: > > 1. There are a *lot* of IF games! > 2. They are small individually. > > Both can be aided by having groups of games when possible -- e.g., one > pack for each IF competition. Also, both would be alleviated if the > "games" category had a subcategory for IF. I'd just like to point out that I'm working on packages for a bunch of IF interpreters using the glk I/O library; I've done Nitfol (Z-machine) and Glulxe (Glulx), and someone's just pointed me to a Tads glk interpreter. There's also a few other things in there that use glk. deb http://plover.net/~hjalfi/debian ./ deb-src http://plover.net/~hjalfi/debian ./ Just in case anyone's doing anything similar. -- +- David Given McQ-+ | Work: [EMAIL PROTECTED] | "Space is the final frontier, and so is the sewage | Play: [EMAIL PROTECTED]| farm." --- Diana Wynne Jones, _Archer's Goon_ +- http://www.cowlark.com -+
Re: Playing with dpkg's mind
On Wed, Nov 07, 2001 at 11:56:34AM +0100, Robert Bihlmeyer wrote: > > In following I call the old version of the package OP, the transition > package TP, and the game file I want to keep GF. why not have TP depend upon GF1 GF2 GF3 GF4 GF5 ? TP is supposed to be a meta-package, right? upon re-reading the proposal, it looks like you want to have an installer be able to go to the FTP site, and grab the games in question. i see this as being done in basically one of three ways: 1) the task meta pacakges of yore 2) qmail-src, that gets a tarball, and then makes a .deb, which is then installed 3) mscorefonts, that gets some .exe's, extracts the fonts, and places them in the filesystem where they belong. mscorefonts gets all the fonts at the time of installation, and has an updater along with it. i am not certain that it allows the selective removal and addition of various games. if i understand correctly: you want a package that allows the insallation and removal of games on an individual basis, but will get a whole bunch at one time. the first half can be done via apt/dpkg. the second half can be done via a meta-package like the -task packages of yore. my 2ยข. -john
Re: Playing with dpkg's mind
I also got confused reading about your intentions. If you are confusing the developers the users will likely be even more confused :) I've played So Far a bit and wouldn't like to see it go out of the distribution. So it doesn't have source, in this case who cares, things work fine how they are from user perspective. If it takes extreme contortions to fix better to leave it 'broken' in this case I think. Of course, if there is some straightforward way to make it policy complient that would be good. The bug doesn't say how it fails to meet policy. On Wed, 7 Nov 2001, Sean 'Shaleh' Perry wrote: > On 07-Nov-2001 Robert Bihlmeyer wrote: > > Hi, > > > > I want to move the various interactive fiction games from their own > > packages to management by a common "installer" package. See #107245 > > and related bugs. The installer package will own the various games; > > any transition packages must end up not containing the respective game > > file so that the transition package can be safely removed without > > purging the game file as well. > > > > I came up with various solutions and can't decide on either one. > > Someone give me a clue? > > > > I am a little confused. In the bug you state your intention is to simply > offer > a downloader that will retrieve the games. So why all of the dpkg confusion > here? Seems mucking with dpkg's files is a BAD idea. Truth is any solution > is > going to lead to a little user confusion. I see debconf in your future. > > Why not do this a simple way? Upload packages of the same name without the > games in it. Then the installer package can handle it from there. Although I > wonder why we even need an installer package since downloading these amounts > to > browsing an ftp archive and grabbing one or two files. Perhaps we should just > remove the packages and forget about it. Not all problems need an engineering > solution. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
