Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
Jason Gunthorpe [EMAIL PROTECTED] writes: 2) A local mirror, hand constructed. No extra or useless packages in there. Apt doesn't construct or handle this type of arrangement well by default. The mounted method deals with this just fine. I'd be interested to know how any other method handles this, how do you inform dselect what packages are in your local mirror so you can select them? dpkg-mountable handles it thusly: 1. If there's a Packages.gz file in the directory, use that. If files from that are missing then -- like your comment about Apt -- it will be a little verbose if you try to install any of them, but will carry on and do the rest. (Because of the way it's written, it won't look for older versions anywhere else right now). 2. For mirrors it thinks of as local, it will use dpkg-scanpackages to construct a Packages file if none already exists, and will keep it up-to-date automatically based on what files are there. (This is a bit bad because it really needs the override file from Master too). Local directory is used to override a source directory, basically like two lines in sources.list; the intention is that the main directory is a Debian mirror, and the local directory can be used for some upgraded pacakges if (for example) the mirror is on a CD-ROM or NFS. Andy -- Andy Mortimer [EMAIL PROTECTED] -- Andy walking, Andy tired, Andy take a little snooze -- Andy Warhol, David Bowie
Re: Bug#32068: multicd can't reinstall removed package
Hi, Martin Schulze [EMAIL PROTECTED] writes: [...] If you install a package (using dpkg -i foo.deb or dselect) dpkg modifies the record in the available file and replaces it with the proper record from the status file (guessed or experienced by Ruud). As a result of this the available file lacks the fields Filename: MD5sum: and X-Medium: which makes it impossible to install this package again since the methods don't have a chance to find out where the package is located. I've found this with dpkg-mountable too; it can also happen if a package fails after a certain point in installation (I think). I never quite worked out when it happened, though. Solution: multicd has to copy the Packages files into $methdir/multicd/ and access them directly instead of the available file. Since this needs a redesign of the installation method and I'm somewhat short with time I'd appreciate somebody sending me a proper patch. The way I solved this was to simply make a copy of the *available* file, after doing dpkg --update-avail in the [U]pdate method, and then parsing that copy in the installation method. If this doesn't work for you, you could always make the copy at the end of the [U]pdate method, and then copy it back at the beginning of the [I]nstall method! (It's not the prettiest method ever, but it would work ...) Hope this helps, Andy -- Andy Mortimer [EMAIL PROTECTED] -- Andy walking, Andy tired, Andy take a little snooze -- Andy Warhol, David Bowie
Re: Slink not installable from CDs
Philip Hands [EMAIL PROTECTED] writes: If there's a way of making multi CD installs work, then I'm all for it. One thing: Do people think it's important to keep the possibility of doing a one CD install, and still ending up with a useful system ? Useful as in boots, yes! But you get that with the floppies ... apart from that, I suspect we'd have to try fairly hard to get a single CD that gave most people a usable distribution ... If so, I would think the thing to do is to move the ``most optional'' packages from main onto the second CD, so that the first CD still contains the ``most important'' bits of main. How do we determine what's important, and what's optional ? A couple of weeks ago, I cut for my own use a couple of CDs of slink (without any of the scripts or anything, just collections of packages). What I ended up doing was putting all of main up to extra -- with a few exceptions -- onto the first CD, and the rest (unsuprisingly) on the second. The exceptions I ended up with were sound and latex, as they seemed least likely to be depended on, but that is probably a bad move as presumably games etc depend on sound. OTOH latex and math, while it would make a fair few people use both CDs, might seem sensible. Alternatively, if pkg-order is still around (I just checked, of course it is!), we could do it by getting a list from that and keeping on adding packages until it gets full? Obviously this would need a little work (eg, two packages with circular dependencies need to be on the same CD), but it seems workable to me, and has the added advantage that it's scalable to n cds for any (reasonable :-) n. Or even to floppies, ZIP discs, you name it, although floppies would be majorly masochistic ... Is something like ``Anything with a priority of extra gets put on the second CD'' a reasonable guess ? The first CD was still too big when I tried that, but I wasn't doing too precisely; YMMV. On the same topic, nobody has yet mentioned dpkg-mountable as a possible for the multi-CD install, as it was for Hamm. I didn't really have time to think about this for Hamm, as I was busy getting married and stuff (you know how it is ... ;-), but I've given it a little thought and, so long as the packages are reasonably well ordered, it works quite well. I managed almost all of it in a couple of iterations of my CDs, and didn't need the extra knowledge of which CD it had. (It just spewed lots of errors; it could certainly use that knowledge if it was available!) It could work either by reading Packages files from both CDs, or putting all the Packages files on both CDs. Also, another data point (and BTW, please don't think I'm being defensive) is that last time I looked at it, apt still required a fairly clean system to start with. Hopefully this has changed while I've been out of touch. OK, that's enough from me; fire away! Andy
Re: About the Hamm Freeze (!)
Dear all, I'm a little late with this, unfortunately, but here goes anyway ... Martin Schulze [EMAIL PROTECTED] writes: I was told that dselect has problems with hamm being distributed on more than one cd rom. Ian Jackson suggested that we should take a look at dpkg-mountable. This means that a) dpkg-mountable might need to be included in the boot floppies and b) we'll need at least one another set of boot floppies - or someone invents a different method for this. Erk. dpkg-mountable has at least one problem which might cause problems: it currently doesn't support predependencies. If the autoup.sh script takes care of all predependencies, that's fine; otherwise, people are going to have to export DPKG_MOUNTABLE_PREDEP_SUPPORT=yes before their first upgrade. The only reason for this is that I wanted to get the other bugfixes into Hamm but I didn't have time to test it well enough. If it is necessary, it'd be good if people could test running with this and let me know if it works or not (I'm fairly sure, based on later experiments, that it will), and if there's time I'll upload a version with predepends support enabled by default. Happily, this is already copied to the release manager, whose decision it should probably be what happens here; I just think it's fairly important to get a decent first install. This is based on the idea that only packages up to a certain priority are included on the first cdrom and lower priorities are distributed through the second one. (I also have another change which installs packages in order of priority, which is in my local tree, but unfortunately I coded too long after freeze for it to make it in. If people want it I'm happy to upload this too, though.) Thanks, Andy -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- This is the noise that keeps me awake. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Predepends query
Jason Gunthorpe [EMAIL PROTECTED] writes: On 7 May 1998, Andy Mortimer wrote: I guess it comes down to: does breaking dpkg-mountable count as stopping the system functioning? Comments would be appreciated. A PreDepends will do nothing to assure the safety of an already installed package, that is, as I understand your situation a PreDepends will not help solve your particular problem. True. So if they don't have it installed they obviously aren't using it, and so it won't be broken; once it's installed, it won't make any difference anyway. I guess I might as well not bother, right? Thanks, Andy -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- The people are fading away, as I slip into colours then ten shades of grey; If I don't last this one tell them when I've gone, That playing with you was incredible fun. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Predepends query
I've just been testing the new version of dpkg-mountable -- nothing exciting, I'm afraid -- using a large set of packages to install, and I've hit a small problem. perl-base was predepended on by something, which caused it (using the usually-disabled predepends support) to remove perl. This broke dpkg-mountable, and I had to install perl by hand. Now, for me, this was trivial, as I knew exactly what needed to be done. The question is, what about other users? And more specifically, should I make dpkg-mountable predepend on perl? This would have the advantage that, so far as I can tell, the installation shouldn't break like this in future (although I have a fuzzy memory of a bug in dpkg which might actually allow this). On the other hand, it's another predepends, and I'm not really sure whether dpkg would handle this situation well anyway. I guess it comes down to: does breaking dpkg-mountable count as stopping the system functioning? Comments would be appreciated. Thanks, Andy -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- I only smile in the dark, My only comfort is the night gone black. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Deb 2.0 testing process
Brandon Mitchell [EMAIL PROTECTED] writes: The testers are starting to think about how to organized the 2.0 testing effort. One idea that the testers seemed to like is to create a checklist for checking each package. [details snipped] Excellent! If this comes off, I think it will probably work very well; certainly, it seems to be the way to go. Apart from anything else, having such a checklist will hopefully encourage the developers to check their packages against it before they release them! OTOH, if you make this too simplistic, then I fear you're going to miss most of the problems: I'm sure the majority of developers do test their packages at least a little bit before releasing them. I certainly do. But one of the things Debian has been bad at in the past is getting a distribution which is consistent within itself, and that is something that these checklists won't address. That little niggle aside -- and I'm sure you will be doing other things than just this -- the testing made a big difference to Bo, and it sounds like it's going to be even better for Hamm. Keep it up! Andy -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- I found myself alone, alone above a raging sea That stole the only girl I loved and drowned her deep inside of me. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: auto compiling
On Jun 28, Andreas Jellinghaus wrote here are my auto compiling script. there is a bit more management in it, and i seperated the whole thing in two scripts (the basic idea was, that they could run on seperated machine, or the build script could run in a chroot environment for security...). Thankyou, I'm sure they're very nice. But please don't send things like this to the list: they aren't very big on their own, but some of us do have to pay to download email, and the more people do this, the more stuff I *have* to download that I'll probably never use. Instead, make up a simple package of it, and stick it up for FTP somewhere (I would suggest experimental, but that's no longer allowed, is it? Where's the canonical place for this sort of thing now?). Then post your changes here, and interested people can download it themselves. Thanks for your time, E -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- Your face! I'll never see you this way again. I captured it so perfectly, as if I knew you'd disappear away. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
On Jun 24, Santiago Vila Doncel wrote But I still dislike automatic building. If you just want not having to fetch the source package, what about a foo-doc-texi binary package (on a do whatever you want with it basis), which just ships the .texi source? Better still (IMO, of course :) would be to have a foo-doc-source (AKA foo-doc-texi, except that it isn't necessarily texinfo; it could be SGML, for instance) package, which can be used to make *packages* containing the docs in whatever format you require, which could then be installed and deinstalled in the normal way. A large problem with this is keeping the versions of documentation installed the same as the version of the package. Another way to do it might be to distribute `dummy' packages foo-doc-html and so on, which depend on the foo-doc-source and which generate the correct form on-the-fly. This would save mirror space, but would require the doc-source to be installed (since it would have to Depend on the doc-source package). E -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- I found myself alone, alone above a raging sea That stole the only girl I loved and drowned her deep inside of me. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking my leave/Packages available
On Jun 17, Larry 'Daffy' Daffner wrote svgalib (svgalib1, svgalib1-bin, svgalib1-dev, aout-svgalib which probably doesn't need any further updates) zgv I'll take zgv, and I'm quite happy to have the svgalib ones too if nobody else wants them. Cheers, E -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- The illusion is deep, it's as deep as the night, I can tell by your tears you remember it all. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
On Jun 13, Helmut Geyer wrote Our aim for Debian 2.0 is to provide all libs as reentrant. It usually isn't enough just to compile it with -D_REENTRANT. You have to avoid static and global variables and do some mutex locking. Can anybody point me to some more information about this? If I'm going to need to change Giggle to be reentrant, I probably ought to start fairly soon, especially since it does make fairly heavy use of one global data structure. Even some simple example code would be very useful: which libraries are currently reentrant? Cheers, E -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- It goes dark, it goes darker still; please stay. But I watch like I'm made of stone, as you walk away. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
On Jun 13, Bruce Perens wrote Regarding how to make your library re-entrant, you must have no global or static variables that are not protected by mutexes. In general it is easy to deal with this by passing your state structure as a pointer argument to all of your functions rather than by using a global variable. Although how well this interacts with dynamically-loaded shared libraries is anyone's guess; I suspect I may have to go the global-variable route myself, which is why I was asking for examples/docs. I don't know what state S-Lang is in with this respect - that might be your first concern. Without having looked at the source, I do know that it uses a fair few global variables for various things, unfortunately. Cheers, E -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- Your face! I'll never see you this way again. I captured it so perfectly, as if I knew you'd disappear away. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
On Jun 14, Rob Browning wrote Andy Mortimer [EMAIL PROTECTED] writes: Although how well this interacts with dynamically-loaded shared libraries is anyone's guess; What do you mean? I'm using libdl, to allow me to dynamically add and remove modules as I go. But I don't really know enough about the implementation of threads (or libdl!) to know how they're going to interact. I shall write a few test progs probably today or tomorrow, but the basic question I want to answer is: if I open a library in one thread, is it then always accessible to all threads (presumably), and what happens to any global variables in that library? I suspect I may have to go the global-variable route myself, which is why I was asking for examples/docs. [snip example] See man pthread_mutex_init and other pthread_* man pages in libc6-doc. Thankyou muchly; that should get me started! E -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- To sleep: perchance to dream: ay, there's the rub; For in that death of sleep what dreams may come When we have shuffled off this mortal coil -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: points on future installation disks development
On Jun 9, Sven Rudolph wrote My ideas on boot-floppies' future: - rewrite dinstall in C - reasons: - runtime improvements - don't run fdisk -l that often - todo: make a libsfdisk from sfdisk - more complex datastructures (avoid using sed often) - more complex input masks and consistent user interface - network configuration: everything in one screen - selecting base directory in one screen - use : - ncurses and libdialog (from FreeBSD), or - slang (ncurses shouldn't be needed then, slang is said to have a curses emulation), or - turbovision (licence OK?), or - something else (suggestions welcome) Please check out my Giggle library, which can currently be found at http://asm21.emma.cam.ac.uk/~asm21/giggle.html, but will be moving in just under a fortnight[1]. It is currently under development, but is basically designed as a flexible interactive information gathering library (as distinct from UI library, which is much more general). There is currently only one module for it, which uses S-Lang and gives a `dialog'-like feel to the interface, except it seems to be (mostly) quite a lot faster; I have also written a basic dialog command-line clone, which seems to work fairly well. Advantages for this application are: * Interfaces (IMO :) very easily to C code. * Would be able to provide alternative modules for different purposes (such as a simpler one for a brail interface?), with no recoding. This also makes the provision of an X-based install much more reasonable (although IIRC dinstall won't still be running by then?) * Designed for reasonably easy i18n (some details still to be worked out, and then I planned to ask the Debian teams to look at it). As well as some things like context-sensitive help which would probably be quite nice. ;) Having (finally!) finished my exams, I'm just converting all my source trees to CVS, and then I shall go back to work on it, and hope to have a usable set of libraries within the next few weeks; it's certainly OK if you're relatively clued up ATM, but it's not polished enough to join the distribution! I'm very keen to add new modules etc, and for other people to do the same (any X programmers? ;), and a couple of the features which you've listed below could be done with alternative modules: - new features - installation via serial terminal - for blind users I have no idea how brail terminals work, but this should be possible. - for automated testing A `response file' has been planned for a while, which would allow this sort of thing. - use lilo in order to drive the serial line early (or modify syslinux ?) (what about GRUB ?) - an extra command-mode installation ? - installing base via ftp and smbfs (and from tape ?) - mouse support ? (gpm, or derived from gpm) This should go into the slang method at some point. Although its normal mode of operation is to dynamically load modules, it would be fairly painless to make a statically linked version (a metter of a couple of defines, in fact), which would also remove the need for libdb etc. [snip] Related topic: I expect to have much less time for Debian for the remainder of this year. So I definitely need help here; especially for the UI part. I don't know much about UIs in general, but I'd be more than happy to help (read `do most of the coding' :) if you ended up using Giggle. I'm quite happy to help in any case, of course, but I know more about Giggle! Cheers, E [1] I don't yet know where. :( -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- I open my eyes, and look at the floor, And now I don't see you anymore. pgpXOXhUDeTjo.pgp Description: PGP signature
Re: points on future installation disks development
On Jun 9, Sven Rudolph wrote Andy Mortimer [EMAIL PROTECTED] writes: On Jun 9, Sven Rudolph wrote My ideas on boot-floppies' future: - rewrite dinstall in C - reasons: [snip] - more complex input masks and consistent user interface [snip] Please check out my Giggle library, which can currently be found at http://asm21.emma.cam.ac.uk/~asm21/giggle.html, but will be moving in just under a fortnight[1]. In general this sounds to be useful. * Would be able to provide alternative modules for different purposes (such as a simpler one for a brail interface?), with no recoding. This also makes the provision of an X-based install much more reasonable (although IIRC dinstall won't still be running by then?) For the boot-floppies purpose we won't need any X interface. And there was I thinking X would go on the boot floppies. ;) I'm not sure that this is such an issue for dinstall, but depending on how it gets split up, some packages (modconf was the example I had in mind) would benefit from a `native' X-based display. The only needed alternative interfaces is simple command-line (like a terminal without direct cursor addressing). giggle could try to support this, e.g. by converting a message box into a text line and Preass Enter to continue or by converting a list box into a list with numbered entries. And in fact it did at one stage -- I wrote it as part of the testing/debugging -- but it wasn't very pretty at all, because I wanted to get the S-Lang one working. But yes, this is certainly possible. I have no idea how brail terminals work, but this should be possible. But as I gathered direct cursor addressing and all the pseudo-graphics stuff can get confusing for blind people, so an extra command-line mode without any direct cursor addressing were useful. (A Braille display usually shows only one line, so one has to navigate through all lines in order to find where something changed.) Even stronger: a mode which limits itself to as few lines as possible (for example, menus across the screen rather than down) would be useful for blind people? Even if we don't use direct cursor addressing, nicer layout can still be achieved by spacing everything out nicely. Although its normal mode of operation is to dynamically load modules, it would be fairly painless to make a statically linked version (a metter of a couple of defines, in fact), which would also remove the need for libdb etc. Right. I didn't stress that we have strict disk space requirements. But replacing ncurses with slang should give us some room. Assuming nothing else -- like cfdisk -- uses ncurses, of course ... I don't know much about UIs in general, but I'd be more than happy to help (read `do most of the coding' :) if you ended up using Giggle. I'm quite happy to help in any case, of course, but I know more about Giggle! This is a good argument for giggle. :-) E -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- I sing of you in my demented songs. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
On Jun 8, Kai Henningsen wrote [EMAIL PROTECTED] (Bruce Perens) wrote on 03.06.97 in [EMAIL PROTECTED]: [dselect fails to install main packages depending on ones in non-free or contrib] Well, this is one thing that dpkg-mountable seems to get right. Maybe other installation methods could be fixed to do the same? In short, dpkg-mountable does not scan through the archive and unpack every package it finds that is wanted, it first tries to locate the packages and then unpacks them in order. Alphabetical order right now, actually. ;) Actually, it has problems, too - dpkg-mountable doesn't (yet?) understand pre-dependencies, except to complain about unresolved ones. No, it still doesn't, but this should be coming in v0.5 in the next couple of weeks, once I've got Manoj's pkg-order working; in fact, it'll do full ordering of the install by dependencies, thereby hopefully making a one-pass from-scratch install possible. I would have done this a while ago, except for exams, but they're thankfully now over! E -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- I found myself alone, alone above a raging sea That stole the only girl I loved and drowned her deep inside of me. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upgrading from 1.1 to frozen
On May 28, Ian Jackson wrote Do dpkg-ftp or dpkg-mountable modify /var/lib/dpkg/available directly ? I doubt it. Certainly dpkg-mountable never modifies any system files directly, since (as I'm sure you're aware) this is a rather silly thing to do, and IIRC from reading the dpkg-ftp source that doesn't either. In fact, I believe that dpkg-ftp keeps it's own copy of the available packages database, totally seperate from dpkg's. Yes, I do *read* the available file, as well as the status file. But all writing is done via dpkg, as it should be. [snip: this could be the problem] If a dselect method script just copies the file instead then dpkg doesn't get a chance to do this check. Perhaps someone decided that the 0.001 second saved by not having to parse the file is worth the extra hassle for the users of having their dpkg broken, or that they didn't understand the --merge-available or --update-available functions so clearly they should just bypass them. Do I detect a hint of sarcasm there? dpkg-mountable should never have been written in the first place. But the functionality it provides was sorely needed, and so I adapted a script which I had been using locally for a while, packaged it up, and uploaded it for the benefit of others. Yes, it is faster than the `standard' methods, or was last time I compared; yes, I do happen to think that this is a good thing. But I would like to point out that if I was purely after speed, I wouldn't have written in Perl; dpkg-mountable exists because it provides features (logging, md5 checking, parallel trees) that dselect doesn't, not simply because it's a little faster (I'm not even sure if it is any more, I haven't checked since v0.2). Perhaps dpkg should encrypt /var/lib/dpkg/* to stop random packages from messing with it ? Yes, that's a good idea. Really. I don't find it at all useful to grep the available packages file, or to modify package scripts that don't work. If you had approached me politely, I would be more than happy to explain what I've done; I would still be happy to do so. Had you limited this post to asking whether or not this could be the problem, I could have replied simply that it wasn't. But I found the second half of your post offensive, and totally unnecessary. If you still have a problem with this, please respond by private email. Somewhat miffed, Andy Mortimer Author, dpkg-mountable. -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- To sleep: perchance to dream: ay, there's the rub; For in that death of sleep what dreams may come When we have shuffled off this mortal coil -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
list of bashisms
There has just been a long list of bugs against packages using `bashisms' in their scripts, and I can certainly remember this issue coming up before. But I don't know about anyone else, but I certainly have no idea what features are available in the `original sh'. Is there a list somewhere, which developers could use to ensure that scripts which require bash use it explicitly? Otherwise, I'm hanging onto the bug reports, and I can make a list of the things which have come up, but since I don't know anything about it that's probably not the best solution! Cheers, E -- Andy Mortimer, [EMAIL PROTECTED] http://www.netforward.com/poboxes/?andy.mortimer Finger [EMAIL PROTECTED] for PGP public key -- I only smile in the dark, My only comfort is the night gone black. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
dpkg/DEITY feature request (was Re: e2fsprogs_1.07-1 still in 'experimental' !)
On May 14, Yann Dirson wrote Version 1.07-1 in experimental of e2fsprogs has been superceeded by 1.10-2 in unstable. I think it should be removed. (experimental shadows unstable on my system; I think this is normal...) This shadowing is all to do with the order of directories at the [U]pdate step: if a package occurs more than once with different versions, the later occurrence overrides the earlier one. So if experimental comes last in the list, it will shadow unstable; if it comes first, it will be shadowed. I know that dpkg-mountable allows you to change the order of directories in [A]ccess, but it should be possible to do in most access methods. Having said which, it's far from ideal, the way it is. Some, of course, would argue that you shouldn't be installing automatically from experimental anyway, but I disagree. What would be nicer would be a mechanism to somehow store *all* available versions in the Packages file, along with where they came from, and let the user choose which to install. How about it, guys? Could this go into Deity? Cheers, E PS To get files moved/deleted on the FTP archive, file a bug against ftp.debian.org. -- Andy Mortimer, [EMAIL PROTECTED] http://www.netforward.com/poboxes/?andy.mortimer Finger [EMAIL PROTECTED] for PGP public key -- Would you pay life's pleasures to see me? Does it hurt, for I want you to remain? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Source Formats and Source Package Verification
system. * [3.4] It should require only moderate changes to dpkg-dev and to the FTP installation tools. I don't like to make work for myself, and I especially don't like to make work for Guy Maor. Any proposed changes should be able to be implemented by a single person by July first. If source packages were just a specialized format of the binary package format - they could be handled the same way, and using the same tools. Ask Guy which part of the tree is more consistant and easier to handle - the source code part or the binary packages part? Surely a lot of the inconsistency here comes from the fact that one package -- one file in the binary tree, but not in the source tree. None of the mechanisms recently discussed are going to change that, so far as I can tell. * [5.1] Binary package verification (the issues here are substantially similar to those of source package verification). We should use the same package format for binary and source packages, so they could both be signed the same way. We could, yes. But why should we? I think this is too early to be discussing implementations, and we should concentrate on working out what we want from this, rather than how we're going to get it. Red Hat does. So? [snip summary] Obviously we're coming at this from very different angles, but the important points for me in Klee's proposal are portability and ease-of-use, rather than reuse of code. It is quite possible to have a fairly sophisticated system, without just hacking something else, and without having to live in monastic seclusion for a month in order to get all the code written! Hoping I've written at least something useful, E -- Andy Mortimer, [EMAIL PROTECTED] http://www.netforward.com/poboxes/?andy.mortimer Finger [EMAIL PROTECTED] for PGP public key -- Give me life, give me pain, Give me myself again. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
