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: 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] > >
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. > > 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. It sounds like you are trying to reimplement Replaces. Why not just use it? -- - mdz
Re: Playing with dpkg's mind
"Lex Spoon" <[EMAIL PROTECTED]> writes: > 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. Me too, no doubt. > 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. I don't think this would work well. At least I don't have much clues how to divide them up. But feel free to provide bundles. > Also, both would be alleviated if the "games" category had a > subcategory for IF. How would this help? One thing that prevents me from packaging up 30 IF games is that it would bloat up Packages.gz (and the archive) for all users, where each individual game would have quite small an audience, and most are non-DFSG-free to boot. One could put those on an apt-able source outside of Debian, e.g. the if-archive itself. But to make more than a handfull of packages needs another semi-automatic process. I'd rather write an installer and let the user choose exactly which game she wants. > At any rate, we already have a system for managing installed > programs. Indeed, but the IF games only need a very small part of the dpkg functionality, anyway. They don't have dependencies, and need no installation/setup apart form being placed in the right directory. > Is there really no way to use it? It is possible but not more attractive to me. -- Robbe signature.ng Description: PGP signature
Re: Playing with dpkg's mind
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes: > In the bug you state your intention is to simply offer a downloader > that will retrieve the games. And this is available already. > So why all of the dpkg confusion here? Seems mucking with dpkg's > files is a BAD idea. Well, my goal is to make upgrading "just work" without downloading more than necessary. But you're probably right in that the contortions are not worth it. > 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. But ... but ... engineering is fun. Think of it this way: we're sweating-off 6 non-free packages for the price of an additional contrib installer package. All without losing any significant functionality. -- Robbe signature.ng Description: PGP signature
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. > > 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. It sounds like you are trying to reimplement Replaces. Why not just use it? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Playing with dpkg's mind
"Lex Spoon" <[EMAIL PROTECTED]> writes: > 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. Me too, no doubt. > 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. I don't think this would work well. At least I don't have much clues how to divide them up. But feel free to provide bundles. > Also, both would be alleviated if the "games" category had a > subcategory for IF. How would this help? One thing that prevents me from packaging up 30 IF games is that it would bloat up Packages.gz (and the archive) for all users, where each individual game would have quite small an audience, and most are non-DFSG-free to boot. One could put those on an apt-able source outside of Debian, e.g. the if-archive itself. But to make more than a handfull of packages needs another semi-automatic process. I'd rather write an installer and let the user choose exactly which game she wants. > At any rate, we already have a system for managing installed > programs. Indeed, but the IF games only need a very small part of the dpkg functionality, anyway. They don't have dependencies, and need no installation/setup apart form being placed in the right directory. > Is there really no way to use it? It is possible but not more attractive to me. -- Robbe signature.ng Description: PGP signature
Re: Playing with dpkg's mind
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes: > In the bug you state your intention is to simply offer a downloader > that will retrieve the games. And this is available already. > So why all of the dpkg confusion here? Seems mucking with dpkg's > files is a BAD idea. Well, my goal is to make upgrading "just work" without downloading more than necessary. But you're probably right in that the contortions are not worth it. > 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. But ... but ... engineering is fun. Think of it this way: we're sweating-off 6 non-free packages for the price of an additional contrib installer package. All without losing any significant functionality. -- Robbe signature.ng Description: PGP signature
