Bug#157131: PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
On Sat, Aug 17, 2002 at 10:41:11PM -0400, Colin Walters wrote: Package: debian-policy Severity: wishlist The attached patch should mostly speak for itself. I think it's great that a lot of packages support DEB_BUILD_OPTIONS=debug now, but if the program is compiled with optimization, it's very difficult to debug. You might want to add a warning that this needs to be tested. Some packages, like glibc or the Hurd, can not be built without optimization (for example because of inline functions not being inlined). I guess this is the exception, and the vast majority of packages build with -O0 just fine. But where it fails it fails spectacularly :) As for me personally, I have made peace with -O2 code. stepi is your friend ;) Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Architecture strings Was: [rms@gnu.org: Re: PATCH: gcc-3.1/criteria.html]
On Thu, May 30, 2002 at 12:49:47AM -0300, Henrique de Moraes Holschuh wrote: Ben Collins writes: Just a heads up on what is about to happen. RMS is complaining that we use cpu-linux instead of cpu-linux-gnu. I know there's a lot of Great. Now I might have a hell of a time to get dpkg-architecture to do the right thing for DEB_HOST_GNU_TYPE and DEB_BUILD_GNU_TYPE... Might as well speak up now, while there is still time. I think the original plan we worked out together on this list a while ago works well enough for now (at least until Wichert comes to reworking the way arches are handled by dpkg). Do please notice we have (at least) *TWO* classes of arch identification strings. What RMS seems to be asking us to do is to change all of them to have '-gnu'. That is *NOT* what I am talking about. Actually, RMS is concerned about the _GNU_TYPEs (and _GNU_SYSTEM of course), nothing else. Note that the Debian arch names don't even have linux in them, they are i386 and hurd-i386, which is bad enough :) Anyway, this can be rectified when arch handling is reworked in dpkg. For dpkg-architecture, fixing the GNU names is good enough. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: init.d scripts and LSB
On Tue, May 07, 2002 at 04:18:13AM -0500, Chris Lawrence wrote: On May 07, Marcus Brinkmann wrote: The LSB is necessary to avoid diversity among GNU/Linux distributions. There is only one GNU system, as such no diversity, and all of what the LSB specifies as far as I have seen it (I have not made a thorough analysis) is simply defined by the one implementation of the GNU system. No, the purpose of the LSB is to provide a standard ABI and API for applications to link and program against, whether or not the underlying system has the Linux kernel or not. It has a strange name for that purpose. Is it just a misnomer? Is the purpose only to run applications that are within the scope of what the LSB defines? What about programs like CD burner software, audio applications and other programs that use kernel-specific ioctls? Are the ioctl interfaces defined in the LSB? For example, one could take LSB binary packages of GNOME, KDE, Mozilla, or OpenOffice and run them on any LSB-compliant system without any changes. I think this is a bit optimistic :) but I see what you mean. For a wide range of application, this would even be correct. If the Hurd includes a Linux emulation layer, which I believe has been the intention of the GNU project since the Linux kernel became reasonably popular, Well, it is certainly possible, and it is not even costly. In fact, at some day our glibc might be ABI compatible to the *-*-linux-gnu ABI, and at this day we would be LSB compliant without an emulation layer. The emulation layer is only strictly necessary for syscalls, and things like ioctl (and maybe for bug-by-bug compatibility with functions like nice(), where glibc did not behave as specified by POSIX... things like that). then it is reasonable to provide the LSB functionality so LSB packages can run on top of it. (Matter of fact, the Hurd's vaunted capabilities of creating process-specific views of the filesystem would make this easier to do than running on top of many other systems; if it links against /lib/ld-lsb.so.1, run it in the LSB environment.) I have absolutely nothing against providing such a layer of some sort. Maybe I just misunderstood Wichert, but when he spoke of a fork of Debian within Debian, I don't think he meant that emulation layer. Similarly, if the *BSD ports progress, and there is a Linux emulation layer available, there is no reason why LSB compatibility cannot be achieved. There are no technical reasons, I agree. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Serious severity
On Tue, May 07, 2002 at 12:12:16AM +1000, Anthony Towns wrote: On Sat, May 04, 2002 at 10:08:51AM -0400, Marcus Brinkmann wrote: I don't care about now, I care about the next release, or the release after that. Then how about you spend a moment thinking about it from _my_ perspective and stop whining until the next release or the release after that. Yeesh. If I wait until the next release happens, it is too late to change anything, and people like you will only tell me to stop whining (sic). Debian development is asynchronous. You have to adopt to that reality. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: init.d scripts and LSB
On Mon, May 06, 2002 at 05:19:07PM +0200, Wichert Akkerman wrote: Previously Jeroen Dekkers wrote: Debian is more than GNU/Linux. I see no reason why Debian GNU/Hurd and Debian *BSD should follow the LSB. This is a discussion we should be having after the release on a forum like debian-project. Sure, why not. If there is anything to discuss, that is. FWIW, I think we should try to use the LSB as much as possible on all Debian ports. Please note the name: `port'. It is a port of the Debian system to the Linux, Hurd or BSD kernel. The Hurd is not a kernel. We want to have the same Debian everywhere instead of suddenly finding ourselves confroned with a fork within Debian. It is Debian GNU/Hurd, so there is no way it can not be Debian. As for the same, there is no way we will follow the LSB up to the ABI specification for example wrt versioned symbols. Nor does it make much sense to do so, except for binary compatibility with GNU/Linux binaries. Which to make it useful in the context of Debian requires a whole lot of more meat into the packaging system. The LSB is necessary to avoid diversity among GNU/Linux distributions. There is only one GNU system, as such no diversity, and all of what the LSB specifies as far as I have seen it (I have not made a thorough analysis) is simply defined by the one implementation of the GNU system. As far as it concerns me, I am not very interested in offering a blanket statement to follow whatever Linux idiosyncrasy a Linux (exclusively!, they don't even pretend to specify anything else, which is quite a long way from the FHS, for example) standard body comes up with. Not to speak of the interesting fact that the LSB specifies everything and their mom except Linux itself (eg the kernel interfaces). Anyway, your expressed concern is unwarranted. In fact, we did in the past some non-trivial work to make it possible to offer the Debian way of doing things on the Hurd as well, and we will certainly continue to do so. There is nothing special in how Debian runs system services, etc, and they can all be supported by the Hurd, and can be made the default in Debian GNU/Hurd if people care enough about it. For example, Roland McGrath split up the init system to make it possible to use a sysv-style init as used by Debian GNU/Linux by default. I don't think that Debian as a whole is interested enough to make policy and design decisions that really fly on all possible systems, including non-Linux systems like GNU/Hurd (thanks to Anthony for reminding me where the priorities are). So you can not expect that everything that is decided now or in the past can be carried over literally to the non-Linux ports. Nor do we have the resources to really follow every decision and cross check it for usability on our port (and if we do in individual cases, we might get flamed for holding up the process against current priorities). I take it that you mean that the Debian spirit (technical excellence, no-worries-approach to installation and upgrading etc) carries over, rather than minute details in current policies, and this, so far as I can see it, is unharmed by the fact that the Debian GNU/Hurd group consists of a merry mix of early Debian members, new members of Debian, and fresh blood. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Serious severity
On Sat, May 04, 2002 at 04:05:39PM +1000, Anthony Towns wrote: On Fri, May 03, 2002 at 05:27:30PM +0200, Marcus Brinkmann wrote: On Fri, May 03, 2002 at 08:16:32PM +1000, Anthony Towns wrote: On Thu, May 02, 2002 at 07:15:09PM -0400, Joey Hess wrote: Seems to me that if bug severity is orthagonal to release criticality People keep saying that, but it's not true [0]. Release critical bugs are those that are serious, grave or critical. Either this is not true, or the BTS documentation is wrong. [[hurd isn't treated the same as i386]] There are many unwritten rules about how bugs need to be treated, and they change depending on what seems the best way to get a working release out. In particular, filing hurd bugs at high severities before release (especially when people are already uploading relatively untested packages with high urgencies) seems likely to lower the quality of woody dramatically. Is important a high severity? According to you, only bugs with severity serious or higher affect the release. According to Ryan Murray, all hurd-i386 related bugs are merely wishlist. Someone on IRC (Culus, IIRC) suggested on IRC (maybe jokingly) that I do not file Hurd bugs in the BTS at all. And, why should the severity only be useful for the release manager, and released architectures? This is a waste of bits, we have the feature right there but can't use it, instead you suggest to hax0r it. Adding arch tags aren't possible in the short term, and it's not particularly clear that they'd be helpful at solving that particular problem. Why are they not possible? Why would they not be helpful, whereas I described here and in my mail to [EMAIL PROTECTED] (for which I did not get a reply so far) how they were helpful to me (or anybody in this situation)? You're quite welcome to hax0r the BTS slightly to make it easier to track hurd bugs. You can, eg, add your own pseudo-header to say X-This-Is-RC-For-Hurd: yes and then grep through the bug spool later to find them all again and upgrade them when you are actually near release. Or have a special submitter address (debian-hurd@lists.debian.org) and use http://bugs.debian.org/from:debian-hurd@lists.debian.org to look over them. Why are arch tags not helping with exactly this? Helping hurd release sometime in the next few years isn't important enough to risk breaking Linux/i386 now. Why should this be so? I am quite dissatisfied with comments like that, because noboy ever gave me convincing reasons (or any reasons for that matter), why a report like: Package: foo Version: x.y Severity: grave Architecture: hurd-i386 should be even seen by the release manager, break Linux/i386 (sic) or be detrimential to the quality of a release. The same goes for a Severity of important without an architecture tag, but with a text that makes it clear that this is a Hurd bug, and thus not release critical. You will have to talk me out of this at a finer level of detail. I can not happily hax0r the BTS when I don't understand why a cleaner solution is not workable, and, so far, I have heard no rationale from anybody why anything I could possibly do that makes sense breaks Linux/i386. I don't want to break anything. I have avoided filing serious or greater bugs for Hurd issues (except for Hurd-only packages) exactly in mind of the release process. I file only up to severity important and even get shit for that. If the severity is only for the use of the release, then give it another name, because it certainly has not the meaning anymore that is documented in the BTS file bug-maint-info.txt. Thanks, Marcus A grave bug is a grave bug. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Serious severity
On Sat, May 04, 2002 at 06:34:32PM +1000, Anthony Towns wrote: Think about it for a while from any perspective but a hurd hacker's for heavens sake. I have thought about it from all perspectives, from the release managers perspective specifically. Think about what should get the highest priority right now, I don't care about now, I care about the next release, or the release after that. I care about the future of Debians infrastructure. If you only have time for current issues, but not for future improvements, I understand that. But please don't confuse the two things. Think about how much time I can possibly devote to your whims about the BTS considering the various other things I can devote my time too. I am valueing everyones time equally high. You could have answered my questions on the technical aspects of the issue in less time than writing your rant. Think about whether anyone else at all can or will do anything about them. Well, I do. Obviously, other people are interested, too, as there are by now several threads on at least two mailing lists about this issue. If you don't have time to discuss it now, but want to discuss it later, why don't you just say so? Or if you don't want to discuss it later, why should it matter if you have time or not? Think about the sort of ratio of effort that's reasonable to put into doing things versus justifying why they're done this way. I udnerstand why things are done the way they are right now. I want to understand why you think it is not possible to improve them in the specific way I proposed. Think about whether there's any real practical benefit to insisting on someone else doing things the way you want, rather than you just hacking around the problem yourself and getting stuff done. I am insisting on someone else doing things the way I want? Is this your attitude towards me reporting a problem in the process, offering a specific technical proposal to fix it, and offering my help in implementing this proposal? If this is your interpretation of what I am trying to do here, I am surely wasting my time. And here I am, thinking it is better to improve Debian's infrastructure and software base, so that we all can cooperate better. I must be surely naive, thinking that this is one of our goals. If you ever wonder again why nobody is offering help on some problem, you now know why. It's because you are not treating problem reports seriously, but instead kill the messenger. Of course there are priorities. But if it is not anybodies priority, they could just ignore it or say so, there is no need to take it up at the personal level. aj, who wishes he'd remember that he'd given up on transparency already No harm done. At the technical level, you succeeded to remain entirely obscure. Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Serious severity
On Fri, May 03, 2002 at 08:16:32PM +1000, Anthony Towns wrote: On Thu, May 02, 2002 at 07:15:09PM -0400, Joey Hess wrote: Seems to me that if bug severity is orthagonal to release criticality People keep saying that, but it's not true [0]. Release critical bugs are those that are serious, grave or critical. Either this is not true, or the BTS documentation is wrong. I would be more happy with a stance like only bugs of severity serious, grave or critical can be release critical or, release critical are those that are serious, grave or critical and effect only architectures that are about to be released. Because this would prevent anomalies like #144678. Some people seem to think that a bug, despite how severe it is, does only ever deserve a wishlist severity if they only affect the Hurd, and that if the Hurd is about to release, that then we should go and bump up the severity of all those bugs to the appropriate level. This does not seem very efficient to me, and makes the definitions of the severities in the debian-doc package (bug-maint-info) null and void, which talk about things like lost data etc, but not about the release or the architectures. There may be subtle differences between the meanings of the various terms, but they are *very* strongly correlated, which is right at the other extreme from orthogonality. They are only corrolated if you want to do that, and it causes anomalies and fraction between developers, and make it impossible to manage bugs for an unreleased architectures efficiently. It would be easy to adjust the definition to make it more useful. I suggested one way to look at it above, taking the architectures into account. There might be others. Maybe you were not really thinking about the problem of unreleased architectures. I agree that for the more common case of a released architectures, the rule bug severity serious == release critical is a quite strong correlation. I am sorry if I clouded this point in the above by making a finer distinction. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Serious severity
On Fri, May 03, 2002 at 09:32:25AM -0700, Grant Bowman wrote: * Marcus Brinkmann [EMAIL PROTECTED] [020503 09:21]: On Fri, May 03, 2002 at 08:16:32PM +1000, Anthony Towns wrote: There may be subtle differences between the meanings of the various terms, but they are *very* strongly correlated, which is right at the other extreme from orthogonality. They are only corrolated if you want to do that, and it causes anomalies and fraction between developers, and make it impossible to manage bugs for an unreleased architectures efficiently. I don't think this clouds the discussion since the unreleased architecture bugs can be handled in a way other than the official BTS. I don't understand what you mean, can you be specific? What other way is there to report a bug in the Debian packaging that only shows up on the Hurd or on BSD, or, for that matter, on some new Linux port (think of svgalib or some other feature not being available)? As crazy as this idea sounds, I think weakening the whole system definitions for the sake of the unreleased parts is untenable. I do not understand what you mean by weakening. I certainly did not suggest to weaken the BTS, what am I missing? Which system are you talking about here? Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Summary of KDE filesystem discussion
On Thu, Jan 17, 2002 at 09:16:54AM +0200, Jarno Elonen wrote: I think you are going backwards in time somewhat. That's the past, and the current trend is to move away from such setup, and some people thought it is even better to remove /usr entirely. How so? What has been suggested instead? The GNU/Hurd system has a symlink from /usr - . And we will also get rid off /X11R6. We are going to stuff everything in /bin, be it directly, through symlinks, or by intelligent (union) filesystems. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Summary of KDE filesystem discussion
On Wed, Jan 16, 2002 at 11:19:25PM +0200, Jarno Elonen wrote: * Many people feel that KDE (and Gnome) is too large a whole to be stuffed in /usr/bin, /usr/share etc and would deserve a separate directory like X Those people have a hard wired path in their mind from virtual path name to physical directory on disk. They are plain wrong, and will need to adapt their partitioning practice and filesystem functionality to reality and technical elegance. Maybe GNU/Linux is not, but the GNU/Hurd is ready (at least principially[1]) to allow intelligent disk space management and still have everything in /bin. I would XFree86 to be moved to /usr/bin at least some day. In days where you can get a 120GB hard disk for 350 euro, I really don't see the need. The trend is to hide the differences between storage devices, not to make it visible to the user. Thanks, Marcus [1] You can't boot yet from a shadowed filesystem, and the shadowfs implementation is not yet ready for prime time. But all the ground has been cleared and cultivated. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Summary of KDE filesystem discussion
On Thu, Jan 17, 2002 at 09:55:12AM +0200, Jarno Elonen wrote: It's that they grow /usr/bin quite a lot faster than any conventional unix tools and make it very hard to have multiple versions of the desktop on a same computer. This is a deficiancy in the packaging system. It applies to all packages in Debian, not only KDE or GNOME. Unlike libc5/libc6 for example, KDE for example consist of quite a few libraries and, what's worse, applications that are called from other applications and cannot thus be version numbered properly. They can. If the KDE and GNOME people are too lazy to implement versioning in their inter-process communication protocols, they should feel the whip :) if that'll make them spurt. The problem is that the authors and maintainers of these programs are eager to deliver immature software to the public, without taking care of the compatibility issues, which can be solved entirely by technical means (and by some design up-front). This error should not be undone by another error (like shuffling files around and stuff them away in a seperate directory). If that is the only way to make it work for now, then of course it has to be taken, but only under the premise that the _next_ version will be fixed so that it can go into the main tree. My own view on this is that it's not good if you have to change the path settings. Therefore I think a good tradeof would be to have symlinks to for example /usr/kde/bin/qtcups/ (or even better IMHO, /usr/kde/qtcups/bin/). Moreover, /usr/kde could be symlink to either /usr/kde2.2 or /usr/kde3. This is what GNU stow does, and you are invited to use it on your system. Now, I happen to like GNU stow, but it is not the Debian packaging system. [BEGIN wild fantasy warning] Of course, it would be better if that could be easily changed per user, but unfortunately we can't(?) do a link like - /usr/$KDEVER/ on current filesystems. That could possibly be solved with a system like in java-compiler and java-vm packages, however. All the application symlinks would point to a single .sh which would then delegate, based on the link's name and an environment variable, bash to either /usr/kde2 or /usr/kde3. Of course, KDE is just an example. If you want such wild fantasies to become true, you should take another look at the GNU/Hurd. ;) Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Online Help
On Fri, Dec 28, 2001 at 10:00:51AM -0700, Chris Tillman wrote: However, some commands don't respond to this, others act as if the --help was not present and do their function anyway. That violates the don't-surprise-your-user software quality guideline, when so many packages conform to the unwritten 'standard'. Annoying, but we can probably not help it. For some programs, there is a historic reason they behave the way they do. For others, we might be in trouble if the upstream authors disagrees. We would behave different than in other systems, which also breaks another kind of expectation. By the way, this standard is not unwritten. It is the GNU coding standard which mandates --help, --version and a lot of other good stuff. I completely agree with you about what's desirable, but I am afraid you can only try to push this idea at the upstream maintainers. BTW, just a small point: Programs which can be executed from the Linux console Mind your wording. Linux is just the kernel of the Debian GNU/Linux system. Even GNU/Linux wouldn't be correct here, as there are other kernels, like the Hurd. I also don't think the restriction to 24 lines makes any sense, but it should print the help output at stdout, so you can easily pipe it to your pager. GNU programs also print usage (--usage) information at error (to stderr) or at --usage (to stdout). Thanks, marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Question about build dependencies.
On Mon, Dec 17, 2001 at 05:19:07PM -0500, Joey Hess wrote: Anyway, one can put a cvs checkout in the build rule w/o breaking any autobuilders, if you're really careful. base-config has had this for ages, without causing any problems: Sure. But it does open a security risk. If people manage to trick the builder into downloading files from their server instead the real one, and use them for building the package, this can lead to serious problems. In your example, it does 'only' affect a list of mirror (attacker could include his own mirror address). In examples where code is downloaded[1], the binaries could include trojans etc. As the source and build tree is often deleted shortly after building, it would be very hard to even notice such an attack. Sure, the cost for an attacker to do this is high. But it's a weak member of a chain, and would defeat all signatures and other methods we try to apply to make our system secure. In theory, packages should never be built on network connected machines. That this is unrealistic is clear. However, in theory this also would mean that such features as your example provided are never used. :) Thanks, Marcus [1] Such an example existed, some binutils-* package did this. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Question about build dependencies.
On Mon, Dec 17, 2001 at 10:20:32PM +0100, Ola Lundqvist wrote: Other checks can be build-dependencies of lynx, omt, ftp and other similar packages. Build dependencies of cvs is maybe a good check too. I've seen it before with other packages. lynx can be used in -dump mode to convert html to ascii. I agree wholeheartedly to not require a net connection. It can be a good idea to run an autobuilder in a secure environment (without net), and in any way, the source should be self contained (except build depends) for many reasons, including security. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
On Sat, Nov 17, 2001 at 09:09:28PM +0900, Taketoshi Sano wrote: 1) Ensure that no program is installed in a state in which it can fail due to missing components, whether they are shared libraries required by the program, missing data, or other programs that are used by the scripts or programs in the package. IMO, this leads to excessive dependencies, since all packages will need to use Depends unless the dependency is truly external and superficial. Many packages will need to be split into tiny sub-packages to keep these dependencies manageable. If this is the way to go, then there may be users who object to have extra (unnecessary for them) packages installed on their system. We should not listen to such objections unless they are reasonable. Reasonable means that the overhead is significant, and the split up in multiple components is easy enough to do. Debian is a general purpose distribution, this also means that we have to compromise a bit here and there. Hidden dependencies are a nuisance to system administrators on multi-user systems, for example. Personally, they would also be a nuisance for me on my desktop system. Some programs allow modularity at the level that some components may be missing and the program will still work (and provide diagnostics if pieces are missing). Such programs might be split up at a finer level than a program that doesn't. After all, it boils down to be a situation that needs to be judged in each case individually. I think my main point is that the split it up at a very fine level is not what every type of user would expect. The pendulum should not swing out too far in either direction. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: packages without .md5sums file?
On Fri, Jul 27, 2001 at 01:07:37PM +0200, Wichert Akkerman wrote: No. .md5sums are the wrong approach for this. The right approach is a combination of signing packages themselves, and dpkg generating (multiple) checksums on the fly when installing a packages. The signing part is implemented already, the second is not currently. Can you elaborate on the advantage of letting everyone generate their own checksums for the installed files? Seems to me a waste of cpu cycles. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: packages without .md5sums file?
On Fri, Jul 27, 2001 at 09:09:55PM +0200, Wichert Akkerman wrote: Previously Marcus Brinkmann wrote: Can you elaborate on the advantage of letting everyone generate their own checksums for the installed files? Seems to me a waste of cpu cycles. We process all the data in a pipe anyway so calculating the checksum takes no effort. Benefits are we don't need to store them on lots of mirrors (space saving), it's more configurable (specify which checksums you want), it's more flexible (easily add new checksums without changing the archive). I think that the checksums should be in the package, and burned on CDs along with the package, so you can verify them more easily. Creating them by an untrusted system, and storing them on writable media (even temporarily) is a process which is difficult to harden. In contrast, if the md5sums are stored in the package on CD, verification is easy: You just need to boot from the (trusted) CD, and kick off the comparison with the CD content. It is easier to trust a list of checksums mirrored world wide and verified by many users than to trust a list which is generated by the system you want to verify. The whole checksums should only take up a couple of megabytes, and any per-file checksum which is cryptographically secure should do. I don't see the need for a lot of flexibility here. Thanks, Marcus
Re: mandate ldconfig -X?
On Sun, Jun 03, 2001 at 01:54:15PM +1000, Brian May wrote: Marcus == Marcus Brinkmann [EMAIL PROTECTED] writes: Marcus We could make it bail out with an error if something is Marcus requested which isn't implemented. Sometimes, Marcus debian/rules scripts run ldconfig to set links. So we Marcus want to provide an ldconfig dummy script which will error Marcus out for any unsupported operation, and only return success Marcus silently for operations which are unnecessary on the Hurd Marcus (as rebuilding the cache). Are you saying ldconfig can't update the links on Hurd? Can this be fixed? Yes, this is what I am saying. It can only be changed by implementing such a feature from scratch or building an ldconfig for the Hurd from the glibc source. Let me however say that this is not a fix, as there is nothing broken in the Hurd in the first place. If you install the Hurd yourself, and not use the Debian binary packages, you will end up with a system without any ldconfig. We just include it in the Debian libc0.2 package for Debians sake. My only concern is that the solution to another policy proposal presented to debian-policy (assuming it still exists) involves moving the symlinks outside of the package, and creating dynamic links with ldconfig instead. I assume you mean #83669. It's targeted at making it possible to compile packages for stable on a system running mostly software from unstable. I think it is ill-advised to implement this functionality in Debian. If you just need a few packages, you can compile them yourself from source. If you do it on mass, you should have a stable chroot, or a seperate machine for it. To answer your question, this conflicts directly with what we expect for the Hurd. But if it is necessary, we'll have to deal with it by providing an ldconfig that creates symlinks. It would be a Debian specific hack, as the Hurd itself does not require this (and we don't want it either). This would allow installing multiple libraries at the same time, if the major number is the same, but the minor number is different. I think it would not be to Debians advantage to allow that. It's much easier for us if IanJ or whoever wants to build for old libraries exploits one of the many possible existing alternative solutions for his problem (building on a stable machine, in a chroot, install older libraries in some other three and compile against them, etc etc). (please send followups to the most appropriate policy bug report). Well, it is rather simple: Roberts proposal and the proposal derived from IanJs conflict. However, if not ldconfig were used to install those library links described in #83669, but some different mechanism (update-alternatives, for examples), both proposals can be implemented easily. Otherwise, if #83669 is implemented, we will have to cope by providing an ldconfig on the Hurd that creates missing symlinks. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: mandate ldconfig -X?
On Fri, Jun 01, 2001 at 04:19:53PM +1000, Brian May wrote: Robbe == Robert Bihlmeyer [EMAIL PROTECTED] writes: Robbe For one, it is unnecessary, and wastes time. But more Robbe importantly, the Hurd has no ld.so.cache, which kills Robbe reason 2 on this platform. Debian GNU/Hurd systems also Robbe don't have reason 1, so there is currently no real ldconfig Robbe program on the Hurd. Rather than writing a program that's Robbe completely pointless, I'd rather we called ldconfig Robbe correcly, i.e. with the -X parameter. ldconfig -X will Robbe just do nothing on the Hurd. I fail to see: What is wrong with the current practise on the Hurd, where ldconfig is a do nothing program? We could make it bail out with an error if something is requested which isn't implemented. Sometimes, debian/rules scripts run ldconfig to set links. So we want to provide an ldconfig dummy script which will error out for any unsupported operation, and only return success silently for operations which are unnecessary on the Hurd (as rebuilding the cache). If ldconfig is called in package scripts, we can not make the dummy script behave reliably: Failing on what is not supported but should have an effect, succeeding on what is without effect on the Hurd. It will also help to catch bugs in library packages on Linux, because missing links won't be created automatically, out of dpkg's control. Although I think that lintian has a check for it. How does disabling task 1 (creating the links) help for the Hurd? To summarize, it will help us catch abuses (incompatible uses) of ldconfig in scripts and package builds, so we don't succeed silently although we didn't perform the requested operation. But beside helping the Hurd, it will also help everyone by making our software better and more more transparent (it is more clear what the intention of calling ldconfig is). It's really just a clean up of one of the many things that are slightly broken. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Tightening up specification of /bin/sh
On Mon, May 28, 2001 at 11:03:14AM -0700, Zack Weinberg wrote: On Mon, May 21, 2001 at 04:43:11AM +0200, Marcus Brinkmann wrote: On Sat, May 19, 2001 at 09:13:31PM -0700, Zack Weinberg wrote: I'd like to tighten this up a bit by requiring that /bin/sh adhere to the consensus of implementations, where POSIX leaves things unspecified. I disagree, on the grounds that this exchanges an arguably specific standard for a completely vague description of /bin/sh behaviour with no understandable gain for Debian. Rather than repeat myself at length I would like to refer you to my responses to Arthur Korn, who said much the same thing. Perhaps you will find the alternate proposal there more to your liking. No, I don't, sorry. I will reiterate, however, that the issue from my point of view is that the standard is not specific at all, and even where it is, it is not readily available, so how does anyone know what it specifies? First thing, in all your proposals is the sentence that says that POSIX is very unspecific. As, like you say, the standard is not easily to come by, we should not make such bold statements without a way to verify it. In practice, the vague description I laid out is more reliable than any impression of what the standard might be, acquired nth-hand from man pages and so forth (I include the Open Group's webpage outlining the shell language in this category). If you have a shell script and two shells, and all three claim POSIX compatibility, and the script doesn't run equally well in both shells, then there is obviously a violation of the standard somewhere. We can expect that at least the authors/maintainers of the two shells claiming POSIX compatibility to have a copy of the standard, or we will have to be suspicious about their claim. So a situation where we have absolutely no idea if and what POSIX specifies about something should be quite rare, and I'd be satisfied to leave this battle to shell implementers. If we come into a double mill, backing off by using less disputed shell features is always an option as well. [...] Debian does not have the requirement that scripts are portable to a large set of systems with unknown shells, which have bugs or weird behavior in border cases. We can always fix our supposedly POSIX compatible shells if they turn out to be not so compatible. I should mention that I am pretty exclusively an upstream maintainer myself and I do tend to come at these things from that point of view. That said, would you not prefer to fix one shell in a border case, than to fix a potentially very large number of shell scripts, which the upstream maintainers may deny are broken? In good faith, since (once more) they have no access to the standard and can only guess at what it might require by the testing procedure I outlined. No, I do not prefer this. I prefer to fix whatever is broken, regardless of the amount of brokeness. I am actually doing this by fixing programs to compile on the GNU/Hurd, which we say is POSIX compliant, but isdifferent from Linux and BSD in that it doesn't specify PATH_MAX (not to mention legacy symbols like MAXHOSTNAMELEN etc). So we have to fix all those programs that are not strictly POSIX compatible, but rely on optional (limiting!) POSIX features which are not available on the Hurd. Indeed, we don't have the resources or possibility to test our scripts against a whole number of shells, or in any other way determine what your idea of /bin/sh is supposed to be. I am not even sure we have five supposedly POSIX compatible shells to test against (not to mention we can have any number of shells which claim to be POSIX compatible, because such a claim can be a fraud). I deliberately chose a number larger than the number of POSIX shells in Debian (three: pdksh, ash, bash). This was to ensure that testing was not limited to shells in Debian. That was probably unreasonable. Yes. I see your point, but for a Debian standard document, this is not so good ;) I think it's a fundamental problem with you proposal, that it isn't a good fit for Debian, where we have different ways to attack this issue. (As we have complete control over what we ship). [...] Certainly the wording could be improved, but I think that a general constraint which can be applied to any number of cases is preferable to a large number of specific constraints. Then we have probably reached a point where we simply disagree in our preferences. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Tightening up specification of /bin/sh
On Mon, May 28, 2001 at 01:05:12PM -0700, Zack Weinberg wrote: So a situation where we have absolutely no idea if and what POSIX specifies about something should be quite rare, and I'd be satisfied to leave this battle to shell implementers. If we come into a double mill, backing off by using less disputed shell features is always an option as well. This leaves nowhere to go if the author of the script and the author of the shell have an unresolvable disagreement. Again, this has come up in real life twice at least. Debian has a protocol to follow if there is a dispute among maintainers. If everything fails, and no compromise can be reached, the technical committee can make a decision. If it helps, we can buy a copy of POSIX for every member of the technical committee. ;) Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Tightening up specification of /bin/sh
On Sat, May 19, 2001 at 09:13:31PM -0700, Zack Weinberg wrote: I'd like to tighten this up a bit by requiring that /bin/sh adhere to the consensus of implementations, where POSIX leaves things unspecified. I disagree, on the grounds that this exchanges an arguably specific standard for a completely vague description of /bin/sh behaviour with no understandable gain for Debian. Debian does have complete control over the shell scripts it ships, so if shell scripts have POSIX incompatibilities, we can fix them. The fear of bugs one might encounter when changing /bin/sh for a completely untested POSIX compatible shell should not stop us from making this requirement. Debian does not have the requirement that scripts are portable to a large set of systems with unknown shells, which have bugs or weird behavior in border cases. We can always fix our supposedly POSIX compatible shells if they turn out to be not so compatible. Indeed, we don't have the resources or possibility to test our scripts against a whole number of shells, or in any other way determine what your idea of /bin/sh is supposed to be. I am not even sure we have five supposedly POSIX compatible shells to test against (not to mention we can have any number of shells which claim to be POSIX compatible, because such a claim can be a fraud). You don't provide a reasonable motivation for such a change either. I don't see a hard need for such a move, be it a large area of POSIX-unspecified behaviour which we need to define, nor a real danger for systems which install an unknown POSIX compatible shell. Also, in cases where disagrement on the correct behaviour does indeed exist (or where optional features should be required within Debian), I favour to explicitely exempt those items in policy, rather than starting from a completely unspecified situation and work it into the concrete. You mention that disputes trigger endless discussions, like echo -n. Your proposal opens the door to even more discussion. In fact, it requires endless discussions, because your proposal is completely unspecific about the details. The attempts you make to specify what is not specified (by making it a necessity to number five shells claiming compatibility, by favouring POSIX over other features, by putting the decision in the hand of the maintainer where no agreement is reached) are failing short because they can easily circumvented formally and thus will not be effective in preventing such discussions. Just saying vaguely that POSIX isn't specific enough is not good enough to justify any change in the Debian policy. That aside, even if there is an understandable motivation to specify what POSIX doesn't, your proposal leaves a lot to be wished for. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote: If noone has a good argument against this I'll send RC bugs in one week to force the upgrade of the Standards-Version. The packages inetutils, gnumach, hurd and mig are only applicable to the Hurd, and we have not determined yet how much and what of the FHS is applicable to us. Most of it is, but we might need an appendix for the Hurd just as there is an appendix for Linux. In any way, I will bump the number if it makes you happy on my next update, and Jeff Bailey took over maintenance of GNU inetutils, he is preparing an update, but I wouldn't consider an old standards version a release critical bug. You will have to bother and check each package individually if there is actually a violation of current policy or a critical bug that warrants a release critical bug report. GNU Hurd Maintainers (bug-hurd@gnu.org) gnumach GNU Hurd Maintainers (bug-hurd@gnu.org) hurd GNU Hurd Maintainers (bug-hurd@gnu.org) mig Marcus Brinkmann ([EMAIL PROTECTED])inetutils Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote: Policy says: -- snip -- In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. -- snip -- Ok, please ignore my other mail. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Definition of Binary field in control file
Hi, this is the remains of a discussion taken on debian-devel (Packages vs Sources), which did not provoke any reply in the last couple of days. I plan to develop this into a policy proposal, but as I feel the issue might be contentious, I think it wouldn't be bad to announce it so discussion can start before a formal proposal is send in. The issue is a violation of the packaging manual in current practice. The definition of the Binary: field in the control file is: 4.2.10. `Binary' This field is a list of binary packages. The term binary package is defined quite directly at the very beginning: The binary packages are designed for the management of installed executable programs (usually compiled binaries) and their associated data, though source code examples and documentation are provided as part of some packages. This manual describes the technical aspects of creating Debian binary packages (`.deb' files). It documents the behaviour of the package management programs `dpkg', `dselect' et al. and the way they interact with packages. Now, current practice is to list *.udeb files in the Binary: field of the control file, which are not Debian (binary) packages according to Joey Hess, and don't match the definition above anyway (they are not `.deb' files and are not processed by dpkg, and they are not provided to be installed on a normal Debian system) I think it is not appropriate to simply document current practice, although this certainly can be done. I think there should be a clean way to differentiate between udebs and debs (and possibly in the future other files) build from a source package by looking at the Sources file package entry (or an equivalent source of information). I'd prefer to either list udebs in their own control field, for example: debian-installer-Binary: anna (The name can be chosen arbitrary). This would provide best backward compatbility, but would limit this to udebs, and future extensions have to be exempted again. Or, the syntax could be extended: Binary: debian-installer/anna This is not backward compatible, but the inclusion of udebs in the Binary field was not backwards compatible to begin with. Personally, I like the debian-installer/anna much better, because it is easily generalizable and very intuitive. Any other syntax which specifies debian-installer along with the udeb name would be nice, any other syntax marking udebs specifically (without mentioning debian-installer) would only provide a very limited service but would work, too. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Definition of alphanumeric?
On Mon, Apr 02, 2001 at 03:07:37AM -0500, Manoj Srivastava wrote: PWD=`pwd` Adam Btw, I think this is bad. They should use CURDIR. __ echo $CURDIR __ So, what is the provenance of this CURDIR variable? Has it been blessed by POSIX? indeed not. However, I see that both $PWD and the pwd utility are sanctioned by POSIX; so for maximal portability scripts should *NOT* use CURDIR, the should either use PWD, or call pwd themselves, like the example did. Note that this is probably not relevant to my problem. CURDIR is the same string as PWD, it is not proetcted so it can be used in make rules like this: foo: $(MYDIR)/bar If $(MYDIR) is something with a : or %, make breaks. I don't know if it is possible to make this work at all by quoting, but this is what you find in gawk currently (with MYDIR being something evaluating to pwd, but chnaging it to CURDIR doesn't change anythin). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Definition of alphanumeric?
On Sun, Apr 01, 2001 at 08:23:40PM -0400, Ben Collins wrote: IMO, Marcus, you should stick with ',' as your : replacement character. Unless you feel like filing bugs on packages that fail with :, which should be ok, since it wouldn't be too outlandish to expect packages to build in an evironment with sane path names (e.g. if I build all of my packages in /usr/src/debian:pkgs/). Another real life example is something like ~/download/master.debian.org/%7Ebcollins/glibc-test/ ^ make doesn't like that either I would indeed prefer to have those builds fixed. Can't be too many (maybe 0.5% total, if at all. gawk is the only example so far). I hope it is simple enough to fix them so they use relative paths (not sure if quoting is feasible or possible at all). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Definition of alphanumeric?
Hi, policy uses alphanumeric to define version numbers. Is this only a-zA-Z0-9, or does this include the _? As the _ is used as a seperator in Debian package file names, this would be perverse, but I would like to stay on the safe side. Background: I use the version number as a directory name in the autobuilder. Unfortunately, make doesn't cope with unquoted colons `:' (epochs!) in target file names, and some packages use something like PWD=`pwd` and use that in rules. If pwd contains a `:', the build breaks (happened with current gawk). There are other characters which must be avoided in the path where you build the packages (like `%'). I want to work around it by replacing the colon with an underscore, or if this is a valid character of a version string, with a comma. If you think that packages should cope with arbitrary parent paths at build time, I would support such a proposal, but I have no time to work the details out myself. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: arch: lines, for not-just-linux debian. (was Re: Hurd and architecture)
On Sat, Mar 31, 2001 at 05:05:00AM -1000, Brian Russo wrote: What's become of the idea of using dependencies for architectures? That scheme could even be extended to subarchitectures or hardware features (ie Depends: i386, mmx, libc6) There are some touchy issues, but it would be easy to emulate the current setup (by having only Debian architectures as virtual names), and transit slowly as time and implementation allows. interesting idea, but i dont like the idea of doing it directly with Depends: theres already what, 4000 packages? 5000? i forget. you're working with an already limited namespace throwing more stuff in there is a Bad Idea (tm) I don't think there are any problems with using the existing fields. The actual set of (mostly virtual) architecture dependency names would be quite small (initially as much as Debian ports, and ideally probably about a few dozens), so this is nothing compared with the real packages. The other reason is that you also need HW-Provides for systems capable to run other systems binaries (like sparc32 vs 64, or binary compatibily provided on BSD and later Hurd systems to run Linux binaries). So you also want HW-Provides, and proably HW-Conflicts, too. And after some time, you realize that some HW is virtual, and some is not, and you have created an artificial difference between those types of dependencies. on the other hand.. maybe doing it with a HW-Depends: isnt such a bad idea.. but, are there really that many programs out there that *need* mmx, etc? There are many more reasons to seriously consider this approach. The right answer to your question is probably: Maybe not, but to properly *allow* programs to use mmx we need a finer distinction between architectures. The flexibility you gain is not much if you just consider the mmx programs. But if I tell you that the Hurd will provide binary compatibility for linux executables, you can imagine that we would benefit from such a setup, because we would not need to recompile a couple of thousands packages (because we would just use the linux binary package for this cpu). consider, a sound card is needed for playing audio files (under typical conditions). so should my package depend on a sound card? i dont think so.. No. Which interfaces exactly should be specified depends on how fine a seperation you actually want and which interfaces are used. Most packages depend on libraries to do their job. So they get a library dependency. A seperation at a linux kernel module level would not immediately be useful (maybe at some later time, I don't know). how does my OS know i have a sound card? it checks for working /dev/dsp at install time or something? what if i dont have the module loaded.. havent recompiled the kernel..etc This is actually a very interesting question, and it is much more difficult to solve than the issue I am concerned with. I would want to limit this topic to hard interfaces like processor etc, which don't change often usually. i dont think the packaging system should try to do everything.. I concur. But using depends for architeture handling at a very rough level (not sound card, but just processor and important kernel interfaces like procfs) is immediatley useful and can save a lot of man power (by eliminating the need to recompile 3000 packages, for example). However, I realize that Debian is probably not ready for this yet, and I would already be satisfied to be able to say: this is linux-all, hurd-all, linux-any, hurd-any. I think everybody can agree to that ;) I wrote something about arch depends in more detail: http://master.debian.org/~brinkmd/arch-handling.txt Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
On Thu, Mar 22, 2001 at 08:23:20AM -0600, Manoj Srivastava wrote: No, you have outlined problems in dinstall and the buildd process. There is inherently no reason not to have multiple versions of a package in the same distribution using package pools, apart from the current implementation of dinstall. Are you sure you wanted to say multiple versions of a package in the same distribution? In my opinion, one version of a package in multiple distributions fits better in the context. If the latter is meant, I concur. There is not technical reason for not building uploads to stable unstable twice in buildd either. I think this is not true. What is meant by this? It means building the same package twice, with the same version number, but the source (debian/changelog) modified to read stable and unstable each once. Modifying the source is evil. Autobuilders should not do this. Having two different packages with the same version number is evil, too. The package pool won't be able to cope for good reasons. I think one of the requirements for uploading to stable unstable should be that the package can be build on either and will run fine on both, so autobuilders are relieved from making a decision. I could agree with setting in stone a variation like: the package must be build on stable and will run fine on both (or build on unstable and run on both). But unless I am very mistaken, we must have one such rule for autobuilders and maintainers to follow. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
On Thu, Mar 22, 2001 at 10:44:17AM -0600, Manoj Srivastava wrote: There is not technical reason for not building uploads to stable unstable twice in buildd either. Marcus I think this is not true. What is meant by this? It means Marcus building the same package twice, with the same version Marcus number, but the source (debian/changelog) modified to read Marcus stable and unstable each once. Umm. No. If I have two buildd's, one for unstable, and one for stable. When a package comes in for unstable, it goes to the unstable buildd, and vice versa. When a package comes in for both, it is sent to both buildd's, and the packlage built by the unstable buildd goes into incoming normally, and the other one is hand installed by an admin into proposed updates or something. Proposed updates. So. That's a factor I did not include in my calculation. (In Germany one would say you catched me on the cold foot ;) Marcus Having two different packages with the same version number is Marcus evil, too. The package pool won't be able to cope for good Marcus reasons. The stable package need not go into the package pool. Am I mistaken in assuming that proposed updates packages are not in the package pool? If I am mistaken, please scratch this part of my message. I don't know. If it is, then you can scratch my messages instead. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: seeking resolution to issues I have raised
On Wed, Feb 28, 2001 at 01:05:32AM -1000, Brian Russo wrote:
On Wed, Feb 28, 2001 at 12:55:16PM +0200, Moshe Zadka wrote:
On Wed, 28 Feb 2001 01:38:09 +0100 (CET), Santiago Vila [EMAIL PROTECTED]
wrote:
On Tue, 27 Feb 2001, Sean 'Shaleh' Perry wrote:
There has not been a consensus on several issues I have raised here:
what to do about cross-compiler directories? Do they belong in
/usr/${arch}?
I think they do. GCC explains how to build a cross-compiler, and it
says /usr/local/${arch}, so /usr/${arch} would be the FHS-ish standard.
That's what every cross compiler in Debian uses, and what every cross
compiler user expects. If FHS says otherwise I would say FHS is wrong.
That's a load of crap -- what if I have two cross compilers installed?
Is gcc going to be given preferential treatment?
It should be in
/usr/lib/gcc/arch,
and play nicely with the othe rpakcages instead of hijacking /usr/lib
wouldn't it make more sense to put it in /usr/lib/${arch}/
or /usr/${arch}/lib ?
That way its easy to look under each arch and see whats installed
etc.
also it will help people who run large sites, and NFS, etc stuff.
There seems to be some confusion about what this directory contains.
The directory /usr/${arch} contains for cross compilation purposes
1. binaries used for cross compilation (gcc etc) in bin
2. header files used for compilation
3. libraries used for compilation
2+3 can be symlinked into the actual root filesystem of the system you build
for. Files in 1 are symlinked to the actually symlinks to
/usr/bin/${arch}-gcc etc on my systems.
It makes perfectly sense for them to be in /usr/${arch}, or even in
/${arch}. You can for example put /usr/${arch}/bin in your path and all
build tools will cross build by default (I am not sure this is a good idea,
though, as it defeats native builds of helper programs).
Marcus
Re: Size limit for compressing files
On Thu, Feb 15, 2001 at 09:57:51AM +, Julian Gilbey wrote: Policy says compress it unless it is small. 4k is an arbitrary choice AFAIK. Not quite so. It is based on the common block size of the file system. If you have a block size of 4 kb, all files between 1 and 4096 bytes will occupy the same space: one block. So compressing them doesn't make any sense. (But then, you are right, as the block size can be chosen at file system creation time.) Marcus
Bug#83669: dynamic creation of libx.so.n
On Mon, Feb 05, 2001 at 05:06:29PM +1100, Brian May wrote: Herbert wrote: As such, I recommend that we change this bug title to: dynamic creation of libx.so.n Herbert Sorry, but this has been solved ages ago in ldconfig :) Maybe so, but then Debian packages shouldn't include the symlink in the runtime library package. Note that the Hurd does not have ldconfig doing anything (its a link to /bin/true to make postinsts happy). Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: [PROPOSAL] Full text of GPL must be included
On Thu, Nov 30, 2000 at 10:26:22PM -0700, John Galt wrote: In the Real-World application, though, installing 300+ copies of the GPL is absurd, and, quite frankly, a waste of space. Which seems the only way to satisfy him. Certainly it's not necessary, as has been pointed out a jillion times already in this thread. We could very easily make sure the GPL is in all the relevant .debs and yet not need to install a jillion copies on the user's disk...(elllipsis added) ...just have a jillion copies in the archives. As there already are in the source archive. Now multiply that by the ~18K that /usr/share/common-licenses/GPL takes. Compressed it is a third of this. All in all it would make about 12 MB per architecture, two thousand additional copies of the GPL assumed. What a deal. Or nr of ports/100 of the full archive. What a deal. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: [RFC] Measuring skills of a Debian Developer
On Sun, Nov 12, 2000 at 07:09:19PM +0200, Aigars Mahinovs wrote: My idea is that every DD's skills in should be recorded. That's counter productive, inprecise and unsocial. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: [RFC] Package build time config for installation directories.
On Mon, Nov 06, 2000 at 09:16:38AM -0500, Itai Zukerman wrote: The proposal makes perfect sense, I just have one concern: I see that dpkg-buildpackage takes an architecture flag, but I don't think there's a way to specify a system type (i386-hurd, for example). If I want to put stuff in /usr/local, should I do i386-linuxlocal, and how? I think it would be nice to: dpkg-buildpackage --system-type i386-linuxlocal (or something). And, if that's the case, probably the system type should be part of the deb (the Architecture field)? It's more complicated. Actually you can specifyu -ti386-gnu to dpkg-buildpackage, but it will be mapped to -ahurd-i386. The Debian Architecture system currently only allows a fixed number of *distinct* architectures. A rough proposal how to change this was written by me (which uses dependencies to reflect architecture requirements). I think it is a bad idea to confuse path's with GNU system types and architectures. It is entirely orthogonal. Please don't mix them up. i386-linuxlocal doesn't make any sense at all. The only connection is that sometimes to mix architectures (32/64 bit systems) you need to specify different default paths. PS. I'm not very familiar with the build process, so maybe this makes no sense. Also, is it possible to compile hurd packages on linux build machines? You can sometimes cross compile (-ahurd-i386) if you have i386-gnu-gcc installed, a hurd partition with libs and headers mounted on /gnu, and the package is prepared for it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: [RFC] Package build time config for installation directories.
On Mon, Nov 06, 2000 at 11:14:12AM -0700, Jason Gunthorpe wrote: A *port* however should not be going around changing things willy nilly. A Debian GNU/HURD system should be very close to a Debian GNU/Linux which would be even closer to a Debian GNU/BSD (due to their more similar kernel design). To turn this into a more constructive direction, I invite you to try the Hurd out and let us know on debian-hurd where we fail to achieve this and could do better. Most of my (Deina GNU/Hurd related) time is spent on packages which are unnecessarily linux-specific, and bring them back in a more portable direction, which should work across any unixish system. So, in my eyes, the best way is not to try to make Debian GNU/Hurd as similar to Debian GNU/Linux as possible, but to make both as similar as possible *to each other*. This is probably what you meant anyway, but I want to point out that this requires changes to Debian GNU/Linux as well as to the Hurd. But this is all blabla. The actual truth is that most changes are simply bug fixes or trivial incompatibilities, and only very few things are really different from a user perspective. To proof my point, the ftp archive contains several hundred packages which are build from the same source as the linux packages with the same name. I know the HURD people want to do interesting and innovative things. IMHO that is a project for FSF GNU/HURD - and isn't really suitable for Debian's UNIX-Like distribution, which HURD is a kernel port of currently. I don't think any person involved in Debian GNU/Hurd thinks this narrow. There is a simple reason: Linux already does all you want in Debian GNU/Linux, and if the only reason for Debian GNU/Hurd is to run a different underlying kernel, the effort is completely boring and wasted, and I'd better not spent a single keystroke on it. And we use /libexec (which is IMHO a good idea), which is something that could be changed if really, really necessary. Frankly I'd drop this. shrug It is against Debian policy and for instance if someone were to file a bug that APT doesn't use libexec I'd promptly close it. Well, we are certainly not going to ask anybody to use libexec in the current situation. It's only the Hurd package installing some files there, I was just mentioning it for completeness anyway. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: [RFC] Package build time config for installation directories.
Am Son, 05 Nov 2000 22:24:35 schrieb Jason Gunthorpe: On Sun, 5 Nov 2000, Ben Collins wrote: 1) Non-FHS ports have problems concering the directories where things get installed (they may not match linux directories). Darwin, FreeBSD, Hurd and many others fall into this category. Could someone explain to me how a non-FHS 'Debian Port' is something we should even be thinking about doing? Is it really Debian anymore? It certianly isn't just a port.. I think Debian is not defined by the FHS, but the other way round: We make good use of the FHS, because it solves a problem we have to solve anyway, and it is a reasonable standard. We try to achieve compliance, but our hearts don't bleed when we are incompatible at any particular time or with any particluar issue where we have good (or even not so good) reasons to be incompatible. The FHS is not existantial for Debian, so I would say, yes, something that doesn't comply to the FHS (note that there is currently no FHS-port of Debian, all ports are incompliant, even i386-linux) can still be Debian. I wasn't aware the hurd Debian folks were actually going to do that within Debian.. That's because Ben is not strictly correct, we are not breaking FHS compliance at will. Indeed, the Hurd author and designer Thomas Bushnell, BSG, was (is?) one of the early contributors to the FHS to ensure that the Hurd *can* be compliant. There are some things the Hurd does differently which only appear to be incompliant at first seight, mainly that the Hurd does not use /usr seperately from the root directory. /usr is a symlink to . on the Hurd (which means all libs in /usr/lib can also be found in /lib and vice versa). Careful reading of the FHS will show that it does allow for any directory to be a symlink, and it doesn't say that those directories may not be identical. Then there are some very small issues where the Hurd is incompliant (but it is a long time I looked into the standard). We have two more root-level directories: /hurd (for translators, which are special programs which can be invoked manually, are installed manually, but usually invoked by the system). And we use /libexec (which is IMHO a good idea), which is something that could be changed if really, really necessary. (Although I think that it is not a bad thing to have a little bit diversity, which adds charm and personality to any system. I mean, linux has some traditional exceptions in the Linux Annex, and there is no reason there could be a Hurd Annex in the FHS to formalize the exceptions for the Hurd. I prefer to work on real code in the meantime, so there is something worth to be formalized :) Thanks, Marcus
Re: RFC: allow output from maintainer scripts
On Tue, Oct 24, 2000 at 03:28:09PM -0700, Joey Hess wrote: Anthony Towns wrote: The sorts of information which currently get displayed, but which don't get prompted for, are things like Restarting internet superserver: inetd, or Updating /etc/network/interfaces: succeeded. Or 40 lines of garbage ralating to byte-compiling obscure emacs modules. Well, yes. Bytecompiling emacs modules: emacs19 emacs20 xemacs20 would be useful output, by comparison. Anything would be useful by comparison (and let's not even talk about the packages that spew tex output to the screen and what users think about that). But consider: one of these emacs packages is installing and it byte-compiles ok. Why should we display the message? Remember staving off boredom is not an answer. I think this is something a user should be able to decide, and not dictated to him by Debian. Ideally you would be able to set the level of details you want to see, and policy only defines a couple of extreme levels (no output at all, verbose == everything) and leaves the medium levels to the package maintainers. The level should be passed to the install script by dpkg (or via environment, also by dpkg or by user). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: file-rc? was: Re: All services that require a restart from libc6 upgrade...
On Wed, Oct 18, 2000 at 01:21:06PM -0700, [EMAIL PROTECTED] wrote: we haven't a script to find out whether a daemon is running yet, but we should introduce one and fixate this in the policy). Yes, this would seem to be the only sane approach. (Other than discarding file-rc and shooting Roland to put him out of his misery.:-) This is fodder for another thread, anyway. Historical reasons aside, is there a Good Enough valid technical reason to discard file-rc? Discarding file-rc won't even help, as the Hurd will have its own init scheme as well, and we need to strengthen the update-inet.d abstraction, not weaken it, for compatibility. Diversion is good :) thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: All services that require a restart from libc6 upgrade...
On Mon, Oct 16, 2000 at 07:04:44PM -0300, Nicolás Lichtmaier wrote: Debian does not ship any other kernel... Eh, so what? Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
Hi, On Mon, Aug 28, 2000 at 05:59:11PM +0200, Josip Rodin wrote: Which is rather unwarranted... all that should be necessary is a executable file that can act differently based on the first command-line argument passed to it. Whether it is makefile, a shell or a Perl script, or even a compiled program (yuck :), it shouldn't matter. Not entirely correct. I am not trying to split hairs here, but it is really important that debian/rules is architecture independant, read: not in a binary format, but a script. The packaging manually actually says it is a makefile: 3.2.1. `debian/rules' - the main building script This file is an executable makefile, and contains the package-specific recipies for compiling the package and building binary package(s) out of the source. It must start with the line #!/usr/bin/make -f', so that it can be invoked by saying its name rather than invoking `make' explicitly. I don't know if Manoj succeeded in making the packaging man a part of the policy. And, I wouldn't mind if perl or shell scripts are allowed (or any interpreter, which probably needs to be in Build-Depends then). They can even compile a debian/rules2 program and use that for further processing. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
On Tue, Aug 29, 2000 at 12:22:44AM +0200, Josip Rodin wrote: Perhaps my logic is flawed; anyway, even if it's not official, the packaging manual should be changed to say that non-makefile debian/rules files are allowed. In this case, you need to replace it with machine-independant scripts or something like that, and probably clean some of the other places where the assumption is made that debian/rules is a makefile. Considering that you can always drop in a makefile which calls the real thing, it's not urgent to fix this, but it might be nice. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Bug#69311: PROPOSAL] Finishing the /usr/doc - /usr/share/doc transition.
On Thu, Aug 17, 2000 at 12:16:34PM +0200, Santiago Vila wrote: Now that potato has been released, I propose that we start deprecating the /usr/doc compatibility symlinks, at the same time we make using /usr/share/doc a nearly-release-goal for woody. [...] I'm looking for seconds for this proposal. Seconded. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED] pgp9Tzvso2V4E.pgp Description: PGP signature
Bug#66023: PROPOSAL] Treat plugins and shared libraries differently
On Sun, Jul 09, 2000 at 01:15:19AM +0100, Julian Gilbey wrote: On Sat, Jul 08, 2000 at 04:17:18PM +0200, Marcus Brinkmann wrote: That is ld.so(8) on my system. Ditto. Actually, since we basically only use ELF nowadays, that should probably be replaced by ld-linux.so(8). I don't know what ld-linux.so is. Please don't use it. Marcus Debian GNU/Hurd developer Oh, that's interesting. On a GNU/Linux system: $ ldd /bin/sh libncurses.so.5 = /lib/libncurses.so.5 (0x40018000) libdl.so.2 = /lib/libdl.so.2 (0x40056000) libc.so.6 = /lib/libc.so.6 (0x4005a000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) So it's not actually linked to /lib/ld.so, but rather to /lib/ld-linux.so. ld.so is used for a.out binaries and ld-linux.so for ELF binaries. I presume there is no equivalent distinction on Hurd? No, we simply use the ld.so from glibc. It would be great if Linux could also drop the special ld-linux.so and aim at a merger with glibc (I thought this was already attempted in the past, seems my memory is at fault). The Hurd exec server supports various object formats (from the bfd library), elf and a.out included. I don't know what the glibc linker supports on the Hurd. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Bug#66023: PROPOSAL] Treat plugins and shared libraries differently
On Thu, Jul 06, 2000 at 09:01:02AM +0100, Julian Gilbey wrote: On Thu, Jun 22, 2000 at 03:35:08PM +0200, Josip Rodin wrote: On Wed, Jun 21, 2000 at 06:14:17PM +0100, Julian Gilbey wrote: I propose prepending text like the following to section 4.3. Shared libraries are .so files containing compiled code that are loaded by the ld.so(5) library. That is ld.so(8) on my system. Ditto. Actually, since we basically only use ELF nowadays, that should probably be replaced by ld-linux.so(8). I don't know what ld-linux.so is. Please don't use it. Marcus Debian GNU/Hurd developer -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: [Re: Bug#66535: proposal of virtual package: syslogd]
On Mon, Jul 03, 2000 at 09:23:49PM +0200, Arthur Korn wrote: I think it would be even better to split up sysklogd into two packages, and then have virtual packages like 'system-log-daemen' and 'linux-kernel-log-daemon' (or would 'kernel-log-daemon' be sufficient? Im thinking on the HURD). Thanks for paying attention. The Hurd can and will have a kernel logger, too, so please use the generic name. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Bug#59403: PROPOSED] restrictions on content of /usr/share/doc
On Sat, Mar 04, 2000 at 05:30:56PM -0800, Joey Hess wrote: Marcus Brinkmann wrote: I agree with the idea in general, but the wording is extremely poor. Reference is not a computer-technical term. It's the same wording that's already used in the policy manual. See my proposal's rationale section. If section 6.7 already has the text, as it doe, what goal do you want to achieve with your proposal, except doubling the information in 6.7 in 6.3? Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Bug#59403: PROPOSED] restrictions on content of /usr/share/doc
On Sat, Mar 04, 2000 at 05:30:56PM -0800, Joey Hess wrote: It's the same wording that's already used in the policy manual. See my proposal's rationale section. Ooops. Sorry for my last mail, I read not carefully enough. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Bug#59403: PROPOSED] restrictions on content of /usr/share/doc
On Wed, Mar 01, 2000 at 06:01:14PM -0800, Joey Hess wrote: A proposal to limit the files that are placed in /usr/share/doc to those that are not referred to by any programs on the system. I agree with the idea in general, but the wording is extremely poor. Reference is not a computer-technical term. We have dwww and doc-base, where docs in /usr/share/doc can be registered and displayed for browsing. Is this a reference? The definition: Nothing must fail if the files are deleted is much better, IMHO.
Re: missing FHS archives
On Tue, Jan 25, 2000 at 01:58:19PM +0100, Wichert Akkerman wrote: Previously Tomasz Wegrzanowski wrote: What about relase goal for woody : with woody one will be able to have (/bin /usr/bin /usr/X11R6/bin /usr/games) stuff in one directory, (/sbin + /usr/sbin), (/lib + /usr/lib + /usr/X11R6/lib) and (/usr/share/man + usr/X11R6/man) also as long as they are properly symlinked. No way. It is already the case that this setup is possible. Note that a namepspace conflict in the */bin, */sbin, */man and */lib areas would be downright silly, as one takes precedence over the other (it is not silly for custom setups, but definitely makes no sense for default setups). Please remember that `GNU/Linux' is a UN*X (alike) OS and should follow accepted UN*X and especially Linux standards. That includes the FHS. The FHS does not say that /usr needs to be a seperate directory tree. In fact, Thomas Bushnell BSG (the Hurd author) made sure that the FHS allows for the setup Tomasz describes above (or, if it doesn't, it at least allows for /usr being symlinked to .). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: missing FHS archives
On Tue, Jan 25, 2000 at 06:15:43PM +1100, Brian May wrote: Marcus == Marcus Brinkmann [EMAIL PROTECTED] writes: Marcus GNU (read: the Hurd) is using /libexec (we don't have Marcus /usr) as well. It is a good idea for some stuff IMHO. Marcus The FHS should probably reconsider its point of view. I think /usr/libexec (or /libexec on the Hurd) is a good place to put small daemons like telnetd, ftpd, etc, that only have one file (the executable). indeed, which is also the default location GNU inetutils puts them in (however, I override it in the Debian package for now). Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: missing FHS archives
On Tue, Jan 25, 2000 at 12:30:24AM +, Julian Gilbey wrote: On Mon, Jan 24, 2000 at 03:56:52PM +0100, Marcus Brinkmann wrote: GNU (read: the Hurd) is using /libexec (we don't have /usr) as well. It is a good idea for some stuff IMHO. The FHS should probably reconsider its point of view. Or GNU theirs. If GNU was involved in FHS discussions, there are probably good reasons why the FHS didn't take their views on board. If they weren't, then they should aim to follow the FHS anyway or aim to get involved in changing it. Or ignore the FHS and make their own standard. Or extend the FHS to their needs. Note that the Hurd is not the other free Unix. Not only anyway. I haven't looked, but I would presume that the Debian GNU/Hurd port is following the FHS, so it can be done. Debian GNU/Hurd packages are mostly identical with the equivalent Linux packages, if they exist. However, we link /usr to . before installing them. (Otherwise, we'll have different Debian systems with radically different filesystem structures, For the issue at hand, radically is a bit of an exaggeration. which just seems to me a very bad prospect, for example, if people choose to migrate at some stage from Linux to the Hurd, and also for sysadmins trying to look at both Linux-based and Hurd-based Debian systems. Besides which, it's the current policy.) There are quite more important issues when comparing Linux with Hurd beside the location of a few daemons. WRT the Debian Policy, we should first figure out what is the best for the Hurd, and then look what changes in the Policy are needed to implement that, and not blindly follow the policy without thinking. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: missing FHS archives
On Mon, Jan 24, 2000 at 12:55:49AM -0800, Jonathan Walther wrote: -BEGIN PGP SIGNED MESSAGE- Instead of being slammed for inventing conspiracies where none would exist, I would be perfectly happy to be proven wrong by someone providing a link to such archives. As so many of you eloquently put, my comments about /usr/libexec make me seem like an idiot because its not in the FHS. GNU (read: the Hurd) is using /libexec (we don't have /usr) as well. It is a good idea for some stuff IMHO. The FHS should probably reconsider its point of view. Thanks, Marcus
Re: Thoughts about src-dep implementation
On Thu, Oct 28, 1999 at 01:16:49PM +0200, Roman Hodek wrote: I don't think it's magic... The problem I try to solve is the following: dpkg-buildpackage works on an unpacked source tree. But src-deps are stored in the .dsc (they really belong there, and this also allows src-dep checking before unpacking or even fetching source files.) So, the problem is to pass the src-dep information from the .dsc into the build tree. No, the problem is where to find the information after the source is unpacked. And you gave the answer: In the dsc file. It should be copied to the target directory (the parent directory of the package tree) by dpkg-source -x just as the orig.tar.gz file is. If dpkg-buildpackage starts, you don't need to have the .dsc; you could already have deleted it. So don delete it if you still want to check source dependencies. Also, if it's still around, dpkg-buildpackage can't know where it is... Source could have been extracted with: dpkg-source -x foo_1.0-1.dsc or dpkg-source -sn -x /some/strange/path/foo_1.0-1.dsc And dpkg-buildpackage later cannot know where the .dsc was... It can be copied along with the orig tar gz. Therefore my suggestion to store the src-dep information somewhere in a file in the build tree. Do you have better ideas? I think my idea above is better, because it leaves the critical information into the place where it belongs. Are there any disadvantages with my suggestion? I would prefer to leave all magic to apt. The only job dpkg-buildpackage should optionally do is verification, which is a yes/no decision mostly. Returning a status like U/I/R, is not something I would like to se at this place. Again, where's the magic? For simple cases, there is no magic. But if the dependencies are complex, for example because they nivolve virtual packages or complex version dependencies, the correct actions to perfom are better figured out by human with the help of apt. Duplicating all the logic in yet another tool seems to be superflous(sp?) to me. All of this does not belong in the standard setup, IMHO. ...what I also expressed explicitly. (I said, this should be enabled by a special option.) I was just agreeing with you. Thanks, Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: Thoughts about src-dep implementation
On Fri, Oct 29, 1999 at 10:16:16AM -0400, Ben Collins wrote: [snip] I'm not arguing for a debian/build-deps file, I don't think it's needed. I just wanted to clarify some details about how to obtain them and in which cases they will be needed (assumably the maintainer will always have the right dependencies, and will be generating them rather than using them, so there is no need for him to worry about it). Yes, I am agreeing with all you said. We have to be careful that we identify the places where build deps cmoe in carefully before jumping to conclusions. Thanks, Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: Build dependencies: some thoughts
On Wed, Oct 27, 1999 at 03:17:52PM +0100, Julian Gilbey wrote: Finally, a small point. It may be worth stating that if a package is required to satisfy an (install-time) dependency of a listed dependency, then it does not need to be listed itself. Although, having said this, I think this is obvious. Forget what I said about it. I didn't grok what you said. Actually, what you say above makes perfectly sense. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Build dependencies: some thoughts
On Wed, Oct 27, 1999 at 03:17:52PM +0100, Julian Gilbey wrote: Firstly, that if we are now demanding build-time dependencies, we are asking maintainers to do a *lot* of work. (This took me about 2 hours, maybe a little bit more.) We ought to think of a better way of performing this task if we want maintainers to take it seriously. No need to get it absolutely right at first try. We can develop this dependency net over time. Finally, a small point. It may be worth stating that if a package is required to satisfy an (install-time) dependency of a listed dependency, then it does not need to be listed itself. Although, having said this, I think this is obvious. I don't think it is a good idea. Mixing them up is flawed. Installing a package is quite different from compiling, and we want to minimize build dependencies (for example, maybe I don't need perl to compile something, but only to run it). It will only make things harder, because now we have to figure out which of the install deps are also build deps and which not. We would suddenly find ourselve on the other side of the problem, and not win much. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 03:46:23PM -0400, Ben Collins wrote: Sbuild calls dpkg-source to unpack, what does it have to do with the source format?! All it has to do is call whatever executable is needed for the unpacking. It _already_ handles _everything_ else, _and_ the Build Dependencies. My suggestion is to keep the enforcement of build deps out of raw tools like dpkg-source and dpkg-buildpackage and in specialized tools like sbuild (which already has it) and apt (which already builds and downloads packages, so it can handle checking build deps with modifications). I agree with Ben that dpkg-source should not care about build dependencies (hey, it only unpacks the source, I only need ar and tar and gzip for this!) dpkg-buildpackage should optionally verify the build dependencies only. apt should have an option to fulfill source depends for a set of packages. sbuild is overkill for most people. Also, it is tightly related to the wanna build autobuilder. It is pretty much hackish, and I would rather see something replacing sbuild than vice versa. All IMNSHO. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Build-depends = change policy wording
On Tue, Oct 26, 1999 at 07:28:31PM +0200, Goswin Brederlow wrote: Source packages should also not depend on other packages with higher priority, otherwise there could arise a situation where you can´t build a package because you can´t build another. This is not useful. Priority rating for source packages is not useful at all. Actually checking that all sources can be build is a fulltime job. There may not be any loops in the dependencies of sources (except for essential and required). Again this is wrong. Circular build time dependencies are annoying but common. I am all for making it easier to bootstrap Debian, but let's first add source deps, and after a year, we can analyze the data with graph theory. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Bug#46516: PROPOSAL] MIME support sub-policy
On Sat, Oct 02, 1999 at 06:51:44PM +0200, J.H.M. Dassen Ray wrote: + p + Packages which provide the ability to view/show/play, + compose, edit or print MIME types should register themselves + as such following the current MIME support policy as + defined in the file ftpsiteftp.debian.org/ftpsite in + ftppath/debian/doc/package-developer/mime_policy.txt/ftppath + or your local mirror. + /p Can we please have this document in a package (the mime package or policy package or whereever)? Referring to an ftp site is not the best option, especially for people who work offline most of the time. Also, updating this with dpkg is preferred. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
starting/stopping daemons in package scripts
Hello, it looks as if we don't have good guidelines what to do about running daemons when installing packages, or I missed them when glancing at the policy and packaging manual. I think it should be specified in the packaging manual when daemons should be stopped, started, restarted, reloaded etc. For example, by using reload in the postinst, the downtime of services can probably be minimized at an upgrade (instead using stop in the prerm and start in the postinst). Of course, some daemons shall require exceptions to the general rule, but it would still have advantages to specify the common case. If someone is interested in working on this, I shall help. Especially I would make sure that the same guidelines apply to the Hurd translators, which are in some ways comparable to daemons (although invoked differently). Comments are welcome, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Bug#45318: PROPOSAL] Ammend contrib definition
On Fri, Sep 17, 1999 at 02:22:20PM +1000, Anthony Towns wrote: Packages that are `too buggy to support' or `fail to meet policy requirements in a serious way' should either be fixed (ideally), or not included in Debian at all. I second this proposal. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Bug#43787: well, here it is: alternate proposal (was: changed title...)
On Sat, Sep 11, 1999 at 02:45:50PM -0500, Steve Greenland wrote: On 10-Sep-99, 08:04 (CDT), Marcus Brinkmann [EMAIL PROTECTED] wrote: Hi, Raul suggested to mention core dumps, which is indeed a good idea. I extended this to give a general rationale for debugging symbols. [*snip* of suggested wording] While I don't feel a real strong objection, I don't think this kind of stuff (rationale) belongs in the standard. It's already wordy enough. Well, it is not without precedence. For a lot of things in the policy, we also give the rationale behind it. I think it only appears wordy because the DEB_BUILD_OPTIONS syntax is explained at lengths. I hope that someday we will find more uses of it (special optimization... whatever else), and then this is moved to another section or so, and we will only have a reference in this chapter (...if `debug' is specified in DEB_BUILD_OPTIONS point). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Bug#43787: well, here it is: alternate proposal (was: changed title...)
On Fri, Sep 10, 1999 at 09:56:24AM -0400, Ben Collins wrote: I don't mind this proposal as long as it satisfies everyone. I'll redo mine to match Marcus's suggested one if I don't hear any complaints. Thanks for your positive response. I hope people speak up if they have complaints, so they can (hopefully) be addressed. Something like this for the options?: -- CFLAGS:= -O2 INSTALL := install -s ifneq (,$(findstring $(DEB_BUILD_OPTIONS),debug)) Note that this does not work, because findstring does search the first string in the second. So you have to use ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g ifneq (,$(findstring $(DEB_BUILD_OPTIONS),nostrip)) Same here of course. INSTALL := install endif endif -- I set it up this way, because I don't think a `nostrip' is pertinent unless building with `debug' also. In this way DEB_BUILD_OPTIONS=nostrip will not do anything, but DEB_BUILD_OPTIONS='debug nostrip' will have the desired affect. Well, I thought about it but didn't saw a reason not to support a single nostrip (without debug). However, I don't really care either way. (I don't think it is a bug to strip if only nostrip is given, on the oher hand, I can't think of a good reason to do that, too.) i would like to hear other peoples opinion on that. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Bug#43787: alternate proposal (was: changed title...)
Hello, I have written down what I think to be a better proposal, which is based on Bens but ended up a bit more concise ;). However, I am not asking for seconds. I hope nobody is offended by this, I just try to be more constructive and productive. I see considerable progress in this discussion, and I hope Ben does bear with the -policy crew just a little bit longer :). This proposal does contain an important bug fix (In you proposal Ben, it needs to be ifneq instead ifeq). Also, by rearranging the findstring options, we can check more than one field in DEB_BUILD_OPTIONS. This latter feature is used to introduce a new string nostrip to address Rauls concern. Last but not least, the wording is different. It says: It is recommended to support building the package with debugging information through the following interface: This is of course what I asked for. I believe this wording still allows for a lot of packages to not implement this feature either because debug does not apply to them or because it is too hard to implement. I believe that the wording, if carefully read, does not make any packages instantly buggy. I also believe that it does allow for packages to implement other interfaces to switch on debugging information along the default interface DEB_BUILD_OPTIONS. I also believe it allows for extension It is flexible (because you can choose between no debug information, debug information, and debug information plus not stripping to build debug packages). I think it is therefore a bit better than the current version. Please comment on this, especially if you find yourself in disagreement with parts of this draft. Ben, can we work towards a common proposal? Thank you, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Bug#43787: well, here it is: alternate proposal (was: changed title...)
On Fri, Sep 10, 1999 at 04:28:08AM +0200, Marcus Brinkmann wrote: I have written down what I think to be a better proposal Of course, because I am utterly stupid, I forgot to attach the beast. --- policy.sgml.old Fri Sep 10 03:45:13 1999 +++ policy.sgml Fri Sep 10 04:10:28 1999 @@ -1966,13 +1966,13 @@ Generally the following compilation parameters should be used: example CC = gcc - CFLAGS = -O2 -g -Wall # sane warning options vary between programs + CFLAGS = -O2 -Wall # sane warning options vary between programs LDFLAGS = # none install -s # (or use strip on the files in debian/tmp) /example/p p - Note that all installed binaries should be stripped, + Note that by default all installed binaries should be stripped, either by using the tt-s/tt flag to prgninstall/prgn, or by calling prgnstrip/prgn on the binaries after they have been copied into @@ -1980,16 +1980,35 @@ package./p p - The tt-g/tt flag is useful on compilation so that you - have available a full set of debugging symbols in your - built source tree, in case anyone should file a bug report - involving (for example) a core dump./p - - p The tt-N/tt flag should not be used. On a.out systems it may have been useful for some very small binaries, but for ELF it has no good effect./p - + + p + It is recommended to support building the package with + debugging information through the following interface: + If the environment variable ttDEB_BUILD_OPTIONS/tt + contains the string ttdebugtt, compile the software with + debugging information (usually this involves adding the + tt-g/tt flag to ttCFLAGS/tt). This allows to generate + a build tree with debugging information. If the environment + variable ttDEB_BUILD_OPTIONS/tt contains the + string ttnostrip/tt, do not strip the files at installation + time. This allows to generate a package with debugging + information included. The following makefile snippet + is only an example how to test for either condition: + + example + CFLAGS = -O2 -Wall + INSTALL = install + ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) + CFLAGS += -g + endif + ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) + INSTALL += -s + endif + /example/p + p It is up to the package maintainer to decide what compilation options are best for the package. Certain -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Bug#43787: well, here it is: alternate proposal (was: changed title...)
Hi, Raul suggested to mention core dumps, which is indeed a good idea. I extended this to give a general rationale for debugging symbols. I suggest the following wording. Raul, does this cover what you head in mind? if not, can you alternate it and suggest a different wording? Replace: + It is recommended to support building the package with + debugging information through the following interface: with: + Debugging symbols are useful for error diagnosis, investigation + of core dumps (which may be submitted by users in bug reports), + or testing and developing the software. Therefore it is + recommended to support building the package with + debugging information through the following interface: Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Bug#43787: changed title, and remade the proposed change
On Wed, Sep 08, 1999 at 08:29:09PM -0400, Raul Miller wrote: This means, packages may choose other ways to specify build with debug symbols, and I can't be sure any longer what to do to get debug symbols (in cases where they are supported). I don't see a meaningful distinction between the cases where they're not supported and the cases where they're not built when the =debug option is set. [If the package maintainer has decided that they're useless, I don't imagine that they would be supported.] In cases it is supported, but not in the proper way, I can file a bug report, but only if doing it the policy way is mandatory, not only because it is a suggestion. [lot's of stuff about tweaking build environment with wrappers deleted] Now you're talking about a case where it's important to build executables with debugging symbols -- and this is a case where it's not the package maintainer that wants the executables built that way. Personally, I've always envisioned doing this by tweaking the build environment. It sounds like you have a case in mind where this isn't reasonable. Raul, how hard do you want to make it for users to build with debugging info? Activating a gcc wrapper, changing install and strip. This is completely unreasonable. Free Software works because people can contribute in finding and resolving bug reports. It is important that people can easily provide backtraces from gdb and similar. The harder we make it for our users to contribute, the less contribution we will get. Indeed, I would prefer we had a way to provide a Debian system with full debugging symbols included. I hope this is possible some day. But this is not achievable currently, I know. Still, I think we should at least try. I hpoe my point is now more clear. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Bug#43787: changed title, and remade the proposed change
On Thu, Sep 09, 1999 at 11:32:17PM +1000, Anthony Towns wrote: On Thu, Sep 09, 1999 at 02:45:19PM +0200, Marcus Brinkmann wrote: On Wed, Sep 08, 1999 at 09:24:06PM -0400, Raul Miller wrote: (2) You want some way to prevent the executables from being stripped before they're installed on the target system. [Depreciating the current unconditional stripping of debugging symbols from packages.] Yes. Along the same lines as (1). Erm. I hope by this that you mean encouraging everybody to make packages buildable either with or without debugging symbols, rather than deprecating that packages be built without debugging symbols or stripped. Yesofcourse. There was never contention about this particular point. Perhaps I should say it again, in all clearness. 1. Packages should by default build without any debugging information, and be stripped. 2. There should be a well defined interface (DEB_BUILD_OPTIONS?) to build with debugging information and not strip the files. (Currently, there is only a suggestion in Ben's proposal). 3. Packages are encouraged to support the interface in (2), but are not strictly required to do so. Patches to support it should be accepted if they don't have negative impact on the package by other means. This does not make all packages buggy, because (3) allows for transition time as long as required for each package individually. Similar to how dpkg-architecture allows for individual transition time. Since Ben's proposal only touches on compilation -- not package building or installation -- you're only addressing (1) at the moment. Erm, what? To my understanding, # DEB_BUILD_OPTIONS=debug debian/rules binary will produce a .deb with full debugging information if the option's supported. In particular, consider the paragraph: ] In order to retain this information in the custom built package, the ] binaries should not be stripped (either with install -s or using the ] strip program). NOTE: This should not be how the package is built by ] default, it is merely for convenience to users wishing to debug the ] programs in the package, or for you as the maintainer to find problems ] when bugs are filed against the package. Ah yes. Allright. But it still says should, right? This means a package maintainer can strip them and still comply with policy. Ben's found something he's happy with, thought it through and written a proposal. If you want something better, the onus is on you to come up with it, rather than demand that Ben satisfy your every whim. It'd be nice if you at least made a *guess* at what would work. Yeah, it seems that I have to make another proposal which will likely change Ben's proposal again to do it right. If this is the way to go, then it shall be it. But I thought the discussion time was exactly for that: Finding out how the proposal can be improved to hammer it in a good shape that will not require fixing it afterwards. (In other words: There will be substantial overlap between this fictional and Ben's proposal, and I really don't understand why people prefer to have two seperate proposals that are very similar instead one that's complete and perfect). If Ben chooses not to change his proposal (which is his perfect right), I withdraw my second, because the proposal does nothing to achieve the goal I head in mind when reading it (the opposite is true). For example: Well, we've got an options setting now, why don't we have, say: debug -- build with debugging information nostrip -- don't strip binaries ? Then when you're building packages normally, you can have debug set in your environmnet, and get the current behaviour, and if you want debuggable binaries, you set nostrip as well. Nono. A single debug option for this is fine. I was just forgetting about that paragraph, sorry. I apologize. I think just a single debug option is more convenient, though, personally. Agreed. Also, I preferred the `stronger' proposals, that said this is the way to go.. but if you really don't want to you don't have to. Thanks. I hope you will then support the fictional proposal we mentioned above when someone (probably me) comes around to submit it. Thanks for your corrections, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Bug#43787: changed title, and remade the proposed change
On Thu, Sep 09, 1999 at 11:48:48AM -0400, Ben Collins wrote: On Thu, Sep 09, 1999 at 08:14:36PM +0200, Marcus Brinkmann wrote: On Thu, Sep 09, 1999 at 11:20:48AM -0400, Ben Collins wrote: You have to implement debugging this way if you are going to support it. Two reasons: 1) Right now policy does not require -g, but only suggests an example, yet everyone is compilg this way. I don't think our developers have to be forced into every possible detail of packaging. Who knows, with the option to do it differently, some one may find a better way. Also, with a suggest, you can always file a wishlist bug to the affect if you want. So they can support either form (their own and the suggested one in policy). Your proposal was concerned about autobuilders. It would be great to have an autobuuilder someday which produces packages with debugging symbols. Only a common interface can make this possible. No my proposal is because of the autobuilder, not aimed at making it better. The point is to get out the -g suggestion from polic while still giving a prefered way of getting the debug info. Yes, and I acknowledge your goal. But I am concerned that people will just drop the -g without replacement, and the rest choose the suggested way or another. What I would like to see is to have some unified way to pass build flags (such as debug) to the rules file. The DEB_BUILD_OPTIONS seemed to fit the bill, but only if people use it. Erm. _If_ you can support building with debugging information, you can make it possible to activate it with parsing DEB_BUILD_OPTIONS. How can this ever be not true? You can't think of an example because there is non. Probalby you are misunderstanding what my preferred requirements would be. You don't know this for sure. I do. If you can write a rules file to build with debugging symbols, you can use this rules script when DEB_BUILD_OPTIONS is set to debug. Always. If you can write a rules file which compiles without debug symbols, you can even make it possible to use it when debug is not set. You just need a simple debian/rules file which parses DEB_BUILD_OPTIONS, and source in the one file if debug is set and the other file if debug is not set. This is even a mathematical proof. I can formalize it for you if needed :) Sorry to see you take this to that extreme. I'm voicing my opinion. If I feel that there is speific agreement that it _should_ be forced instead of suggested, I'll be more than happy to comply and change the proposal. Right now, I don't see any agreement that this is what most want. What I don't understand is what reason there are not to enforce it, because you can always comply, there really isn't a problem, and it is opening the door for a standard interface to pass build flags. OTOH, not enforcing it has the chance that people will make up their own methods, and we missed a way for standardization early on. I had this problem with dpkg-architecture: Many packages used arch=$(shell dpkg-architecture), which did sorta work until the Hurd port came up. Despite the fact that --print-architecture is an undocumented feature and not standardized at all. The result is that many rules script use it, and those scripts are definitive broken on the Hurd. My dpkg-arhcitetcure proposal fixes this situation by providing a standard interface to get the build architecture and make it a requirement. This is a big step forward. In the same way I wanted to see this proposal progress. I was disappointed seeing how little ambitious your proposal ended up to be. Let's see, I was rude to you how? Thanks for the civil reply. Sorry, I was annoyed. At least I managed to flame without calling names :) Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Policy about policy
On Wed, Sep 08, 1999 at 12:34:27AM +0200, Wichert Akkerman wrote: Perhaps we need to add a small layer (perhaps the ctte itself) which sanctions (sprinkles it with holy penguin-pee as Linus would say) updates to the policy as decided by debian-policy. (perhaps sanctions isn't the best word here, I hope you know what I mean though). This would give a more formal framework in which debian-policy operates while not changing the current procedures. So what's the point? Either they sanction everything we do, and then there is really hardly a point to create this additional layer, or they don't, and then current procedures are changed, and we need to pull other means like general resolution, voting etc if there is contention between the policy group and the ctte. Is the Debian project at a stage where we want to create formal frameworks just for the sake of them? All this talk about authorization bothers me a lot. Debian operates from the base, and if the base can not operate any longer because they don't have the power, thinks will stall rapidly, and we will end up with hundreds of little cathedrals who can't negotiate any longer, because it's forbidden (yeah, of course you will now point me to the constitution, and I can pull stuff like general resolutions, but before it cames to that I have long given up. Power plays and politics is not why I joined the Debian project). Am I exaggerating? Probably. But as E.W. Heine said, you have sometimes to aim higher to hit the middle of the target. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Bug#43787: changed title, and remade the proposed change
On Tue, Sep 07, 1999 at 06:10:06PM -0400, Ben Collins wrote: What I mean by that is, if we just say that policy suggests building without -g, then some package maintainers _will_ implement a way of getting debuggable binaries (or objects as your may be). We want this implementation to stay fairly standard, thus the suggested way should be in policy. Why not make the suggestion a requirement. _If_ the package supports building with debugging symbols, then it has to be implemented by querying the DEB_BUILD_OPTIONS variable. I see a) no technical reason to allow other procedures to implement this. b) Allowing other procedures defeats the purpose of a satndard document. This is why I think a suggestion is too weak. You can equally well remove the suggestion, because I can't rely on it and have to check always if a package follows the policy suggestion or does it differently. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Bug#43787: changed title, and remade the proposed change
On Tue, Sep 07, 1999 at 03:14:56PM -0700, Chris Waters wrote: Marcus Brinkmann [EMAIL PROTECTED] writes: On Tue, Sep 07, 1999 at 01:11:33PM -0700, Chris Waters wrote: If the binaries can be debugged in the build directories, then there's little reason not to strip them. That's an assumption that may or not may be met. We should not base our policy on assumptions. The fact that it is not always possible to debug in builddir is enough to cover the general case. And, I may want to distribute packages with debug information to our users, so I can package them and put them on a web page or CD. I think you're getting off the topic here. The goal is to make it so that the build machines don't have to waste time generating debug info that they're not going to use. I would extend this: ... and on the other hand allow users to easily build packages with debug information by following a standard procedure. Extending this to require that all packages be able to build as debuggable versions is an entirely separate proposal, and one I'm not sure we need. I did not say that. But packages which can supporet this should. This is already implicit in the current wording, why change it for no reason? Why cut off options without a reason? Nothing is being cut off -- there is no requirement to be able to create debuggable packages in policy at present, nor has anyone proposed such a requirement. There is already a recommendation to include -g: Generally the following compilation parameters should be used: ... CFLAGS = -O2 -g -Wall # sane warning options vary between programs ... If we (the project, not individual developers) are not going to distribute packages with debug info included, I see no reason for policy to concern itself with the requirement (or even recommendation) to make it possible to build such packages. This proposal is half baken then. Either we drop the support for debug information completely (which would be a shame), or we do it right and tell maintainers how to implement this support if it is possible and recommend this. To do the last is a win-win situation. We gain faster compiles when no debugging symbols are wanted, and we gain a reliable way to get debug symbols if wanted. I still can't see why you think that it is such a bad idea. You say above that this is not the goal of the proposal. Then remove the suggestion about DEB_BUILD_OPTIONS, because it has no place in it. Or you address the issue and do it correctly. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Policy about policy
Hi, On Mon, Sep 06, 1999 at 01:36:02AM -0400, Raul Miller wrote: It looks like one of the most problematic aspects of my way of thinking is the idea that the opinions of developers should be solicited when policy would impact their packages. This is at least impractical. Noone will have the time to investigate 3000 packages to see if a policy proposal will affect these packages and contact their developers. Also, many developers will not care either way. As a volunteer project, we have to make sure that any solution we come up with does not create too much burden for our maintainers. On the other hand, the same is true for any proposal to how the policy groups should work: If it is too much work to make a proposal and get it implemented, we will not get any proposals and will not make progress. Everyone who cares about policy should at least read Joey Hess' weekly summary and if there are points he is interested in (for example because they affect his package), he can read up the relevant thread in the bug logs and give his input. Is more really needed? I don't think so. Now, I agree that this should be a best effort sort of thing -- it's silly to wait around for a developer who hasn't been heard of for quite some time. I don't think the policy group should be required to contact individual developers. Instead, individual developers are always encouraged to join the policy group. There is a mailing list, an archive, the bug tracking system and a weekly summary. I don't think more is needed. I don't see the need for changing the procedure. Especially I don't think we should hide behind procedures, formalization and voting. In the above paragraph, I don't think that you said what you intended to say. [For example: filing a bug report is an example of following a procedure. Policy is a formalization. And voting.. well.. I agree that pure consensus is more optimum than voting.] Perhaps I should have added: I don't think we should hide ... more than necessary. Perhaps I meant something different. The point is that creating yet another procedure or formalization will not solve the problems we experience. I expect the policy group to be more careful with big proposals and objections now (we have learned our lesson), and this is what really helps. So, anyways, while I appreciate your comments, I hope you understand that I'm feeling my way around here -- I'm not ready to propose anything, and won't be for quite a while. Mostly, I don't want to operate in the dark: proposing random constitutional ammendments isn't going to make me feel any easier. If this is the other main point of you we should ask the DPL for approval of our work. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Bug#43787: changed title, and remade the proposed change
On Tue, Sep 07, 1999 at 08:24:06AM -0400, Ben Collins wrote: Ok, this is my last attempt for a crowd pleaser. I hope not. This new an improved proposal should satisfy any and all complaints (as few as they were). This new proposal has several added features. Unfortunately, I dislike the wording in the new proposal. If you want users to be able to rebuild your package with debugging information easily, the suggested way is to use the ``DEB_BUILD_OPTIONS'' environment variable. This is way to weak, IMHO. First, I think as many packages as possible should allow for this feature, so it should not be if you want users to be able, but: if it is possible to build the program with debugging information, so that I have the policy behind me if I file a bug report which implements this change in a package. So, this feature should be optional but strongly recommended. Second, _if_ package implements the feature, it must do it by parsing the DEB_BUILD_OPTIONS variable, or we will never get consistency at all. Hence, I think the the suggested way is much too weak in this context. In order to retain this information in the custom built package, the binaries should not be stripped (either with install -s or using the strip program). First, who says that we talk about binaries? Can we find a more general term like object files? There are also libraries... Then, the object files must not be stripped. Again, should seems to be too weak. NOTE: This should not be how the package is built by default, it is merely for convenience to users wishing to debug the programs in the package, or for you as the maintainer to find problems when bugs are filed against the package. I think this note is unnecessary and can be deleted without substitute. The rest is fine. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Bug#43787: changed title, and remade the proposed change
On Tue, Sep 07, 1999 at 01:11:33PM -0700, Chris Waters wrote: I think that you have far too little trust in the common sense of developers. I think that if policy merely suggests it, most developers will follow the suggestion if it's at all reasonable to do so. I think we should not be sloppy with the wording the Debian policy. We should write down exactly what we mean, and not something that is subject to interpretation. The practical difference between a suggestion and a recommendation in a case like this is effectively nil, IMO. So why not change it then to make the intention more clear? (Of course, arguing this way is moot, and I hope you realize the tnogue-in-cheek here). In order to retain this information in the custom built package, the binaries should not be stripped (either with install -s or using the strip program). First, who says that we talk about binaries? Can we find a more general term like object files? There are also libraries... It could be argued that libraries are binaries. Binary does not necessarily mean executable. This is semantic quibbling. You are quibbling. I am pointing out a point of probable misunderstanding. Again, I would prefer the wording of the Debian policy concise and clear, as opposed to confusing or vague. But I agree that this may be a little confusing, and a more general term might be an improvement. This seems a reasonable change, possibly even a good one, but not really a necessary one. *shrug* Thanks. Then, the object files must not be stripped. Again, should seems to be too weak. If the binaries can be debugged in the build directories, then there's little reason not to strip them. That's an assumption that may or not may be met. We should not base our policy on assumptions. The fact that it is not always possible to debug in builddir is enough to cover the general case. And, I may want to distribute packages with debug information to our users, so I can package them and put them on a web page or CD. Why cut off options without a reason? I frequently do 'debian/rules build', and debug in place, without worrying about the fact that the install rule will strip the binary. Again, I think common sense can fill in the gap here. The Debian policy is what is supposed to fill gaps. If there's no easy way to debug a package, one can always file a wishlist bug (with patches to fix the problem, preferably). Filing bug reports as a solution to solve a uncertainity in the policy? I find your response to my mail very weak. Instead trying to push this proposal through as fast as possible, I would prefer to work out the problems now, even if they are not big issues for you. We had enough problems with sloppy parts of the policy in the past (look at the conffile vs configuration file mess, for example). A few days more or less now don't matter. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Policy about policy
Hello, On Sun, Sep 05, 1999 at 03:07:48PM -0400, Raul Miller wrote: In the wake of the 3.0.0.0 release of debian policy, I've been studying the policy process. Which has worked almost flawlessy for some time before the big FHS bang. Let's not try to fix things that are not broken. Most of the time the policy group on debian-policy (everybody can subscribe) is very productive. We're still learning to organize ourself, but that's only natural. I don't see the need for changing the procedure. Especially I don't think we should hide behind procedures, formalization and voting. If you feel easier if the work of the policy group is official sanctionized, I suggest that the Debian project leader makes the Debian Policy Group a delegate whose purpose is to edit and maintain the Debian policy manual. Then no change in the constitution is needed. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: [PROPOSAL] changing policy on compiling with -g .. a better way
On Wed, Sep 01, 1999 at 01:39:28PM -0500, Manoj Srivastava wrote: + build-debug: BUILD_OPTIONS=debug I suggest DEB_BUILD_OPTIONS for avoiding namespace collision and more importantly for consistency with the dpkg-architecture handling. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: [PROPOSAL] changing policy on compiling with -g .. a better way
On Wed, Sep 01, 1999 at 04:18:55PM -0400, Ben Collins wrote: Looks like this proposal may be turning into a complete subsection on DEB_BUILD_OPTIONS :) Yeah, why not. Makes sense to do this. Since Manoj says the last diff was his last attempt at it, I'll rewrite it to include this and Cc to the BTS. Ok. I didn't check the very latest closely enough, but if it still says if DEB_BUILD_OPTIONS is 'debug', you may want to change this to if it contains debug as a sub string and provide the sample makefile snippet to detect this condition. BTW, I second this proposal. Not that you need my second, but I don't want to leave any doubt about that it is a good idea. Plus more seconds give you fame and glory. ;) This makes it easy to add further options, for example relax to only compile the packages that can be compiled with the available tools (useful for bootrstapping, see Dale Scheetz thread :) of course, those options will be in other proposals. If you don't like this example, ignore it and make up your own. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: /usr/doc transition and other things
On Sun, Aug 29, 1999 at 06:08:54PM +1000, Anthony Towns wrote: Let me put it yet another way. We should be willing to add a lintian check for any additions to policy, and file severity: normal bug reports for every package in violation. (Which isn't to say we actually *should*, but we shouldn't make policy where that would be unreasonable) Does any of that make more sense, and/or seem a reasonable way of avoiding making the same sort of stuff-up again? I think that does not make sense at all. Current practice is a good guidance for the policy process, but being strictly bound to it renders the policy group useless because we had no chance to make real, innovative progress. Let's consider changing the source format. We could either change the policy manual first, and then let packages folow it, or wait until many packages are converted and then adopt policy. I don't see why the second shall be better than the first. Indeed, I see an advantage in the first because we can specify the details in the policy before packages actually implement it, and hence probably avoid confusion or surprises. I also can't see why a package warrants a bug when it does not follow the latest policy. Every package has a standard-version attached to it, which it claims to follow. Only if packages bump the version number before following the policy of this version, it shall be a bug. So, changing the policy manual does not make 3000 packages buggy, because those packages have a different version number. And we don't have a policy about when a package is buggy because it follows an old standard version (although we have a lintian check for this). I think the rule make all packages buggy is very ill guided. Instead, I would like people to see that packages update to new version numbers regularly. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: /usr/doc transition and other things
On Sun, Aug 29, 1999 at 12:09:27PM -0400, Raul Miller wrote: Then again, if you want to change the source format, and policy is ratified which results in source format being unusable during some transition period, that's wrong. Of course this is wrong. The question is under which circumstances is it necessary for the policy manual to give details about the migration from one standards version to another. Sometimes this is necessary (libc6 migration), sometimes I feel we can be a bit more relaxed and only state the final result and let the maintainers work out the details. However, I see there are two places in the policy manual which back up my point. Both are in section 2.4.1: When the standards change in a way that requires every package to change the major number will be changed. So there was the assumption that policy can be chnaged in ways that requires all packages to change. What you seem to propose is that we never bump the major number again. The second was quoted by Anthony already: This value will be used to file bug reports automatically if your package becomes too much out of date. The critical part is too much. These two words give us enough room to *not* file bug reports right after releasing a new policy manual, even with different major number. Hence I would not consider all packages to be buggy, just because they don't comply to the very latest standards version. I believe that introducing major changes in the policy manual and having a smooth transition is not a contradiction, even if all packages suddenly don't comply to policy any longer. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: /usr/doc transition and other things
change gets delayed over and over again. Can you agree that having policy say You can do either foo or bar, but we'd prefer bar is better than having policy say You must do bar, but telling everyone that it's not important that you change from foo to bar just yet if you don't feel like it; even if you think my I agree, but this is not what I say. What I say is: You can do either foo or bar, but we'd prefer bar is worse than You must do bar, and if you don't do it within time we will start to file bug rpeorts Especially I would never say that it's not important that you change if you don't feel like it I hope I explained myself better. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: /usr/doc transition and other things
On Sun, Aug 29, 1999 at 02:11:21PM -0400, Raul Miller wrote: I hope you don't mean that you think the current /usr/doc - /usr/share/doc breakage is appropriate or necessary. I consider this discussion decoupled from this particular issue. (My opinion about the transition of /usr/doc - /usr/share/doc can be found in the archive or get by private mail). For example, I see that first quote from the policy manual as being aimed at times when depreciated policy is pulled from use. I see nothing there which indicates that the policy manual should get a new major version number when new policy is introduced -- before any packages have had a chance to adapt. I agree with your interpretation. I don't agree that introducing a new policy and making it mandatory should be decoupled in most situations. It just doesn't make a significant procedural difference in my point of view (the transition will still happen, and mass bug reports won't be filed in most cases anyway) and has the danger of making the transition more painful/slower. I don't say that we shouldn't take the policy manual seriously. But on the other hand common sense should be enough to see that we don't expect all 3000 packages to be updated in 24 hours. Formalizing this situation any further than the too much out of date part in the current policy seems to be overkill to me. Well, that's just me. I don't like bureaucraz^Hcy very much. I also see a danger of making it too hard to make progress with the Debian policy, slowing down the overall development of the distribution. We already dropped release goals completely. Making the policy less demanding seems to be another step in the, IMO, wrong direction. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: Bug#41232: AMENDMENT 1999-07-23 FINAL DRAFT] Build-time dependencies on binary packages
On Fri, Aug 13, 1999 at 10:42:35AM +0200, Roman Hodek wrote: No. The dpkg-architecture terminology may confuse you. Here's from Packaging Manual 3.0.1.0 section 3.2.1 (debian/rules - the main building script): ... BUILD for specification of the build machine or HOST for specification of the machine we build for. Hmm... it guess I was confused by the GNU parlance: build : arch of the machine we build *on* host : arch we build the program for (i.e., on which it runs later) target: arch for which the program runs (different from host in case of cross-compilers or the like) But we don't want to cross-compile cross-compilers, I guess, so we always have host == target. Exactly. This simplifies things a lot. But I see what you mean: If we consider cross-compiling of Debian packages, some src-deps are needed for the build arch and some (libs and -dev packages) for the host arch. But this obviously leads too far... But we may dream... ;) With dpkg-cross and dpkg-architecture, we are ready for proper cross-compilation setups. This will probably never happen completely, but at least where it is desireable the functionality is there. To make source-dependencies for host architecture work, we would need a cross-dpkg, which can install packages on another architecture. Currently --root doesn't cut it because dpkg will try to run the pre or post install/rm scripts (even with --unpack it runs at least the pre* stuff). This is less likely to become implemented, so the functionality is not yet needed. The decision to leave this out of the proposal was a wise one. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
On Sat, Aug 07, 1999 at 07:57:38PM +0200, Richard Braakman wrote: Marcus Brinkmann wrote: * If so, what syntax should we use? - My choice would be the package (= 42 i386) syntax, as it's the least intrusive choice. allright. But allow a seperator between version number and arch, like (= 42, i386) that's a bit easier on the mind. What happens if you want an architecture specifier but not a version specifier? What's exactly wrong with (i386) or (i386 alpha) and so on? Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
On Sat, Aug 07, 1999 at 02:18:41AM +0300, Antti-Juhani Kaijanaho wrote: If this is not acceptable, the amendment should be marked as rejected. Na, better not. Let's hammer this one in shape now :) * Are Build-Conflicts really necessary? - they appear to be, reading the current list of build-dependencies used by sbuild. Agreed. They may be rare, but necessary. In an ideal world, every source generation scheme would allow for unlimited customization, but unfortunately, we are far away from that goal :-/ * Do we need to conditionalize the build dependencies based on architectures? - Joel Klecker and Marcus Brinkmann seem to think so. I'm not convinced yet. Yes, we definitely need this. There are already packages that require this, and there will be more (for example, when we will tackle upstream sources to support special Hurd features, the package may need special Hurd libraries to compile that are only available under Hurd architectures). Ignoring this feature now would serve no one, as it must come anyway. Let's do it right from the very beginning. (Look at the mess that the current architecture setup, linux makedev in binary-all for example, very annoying for the Hurd port. We should learn from this experience and not repeat such overseights). - This would complicate the syntax Only for those packages that make use of it! Those will be only a few compared with the complete distribution for some time. This is also not hard to implement. You can make use of dpkg-architecture in dpkg-dev! This does already give you Debian arch name, GNU CPU and GNU system string (linux or gnu for hurd). If you want, you can leave this out of the implementation and I will do it when the other features are all supported. Then I add this later-on. Nothing requires the implementation to be perfect from the beginning, but let's not go through the policy proposal/amendment cycle again just for this additional feature, because this will delay it by several weeks. * If so, what syntax should we use? - My choice would be the package (= 42 i386) syntax, as it's the least intrusive choice. allright. But allow a seperator between version number and arch, like (= 42, i386) that's a bit easier on the mind. * Should we use four fields or six fields? - In my opinion the four-field choice offers no real advantages (I've discussed my position in detail earlier) I think the six fields don't offer a real advantage over the four, but I have no string feelings about this and either is fine for me. * When are versioned dependencies necessary? - Ian Jackson wants to allow the current stable as the base where versioned dependencies are not necessary As stable changes, we would end up adding and removing version information in each release. I don't see this happen (read: nobody will care and the version info will stay even when a new stable is released), so I think in practice most people will end up doing it the other way anyway: - I've stated my position earlier: use versioned dependencies every time the non-versioned dependencies would introduce a possibility of a broken build, regardless of releases. I'd like us to reach a consensus on these points during the week we have left. If we can't, the proposal should be marked rejected. (And possibly a new, revised proposal sent out, if necessary.) As you see above, the only point that I definitely have a strong opinion about is the arch specific source dependency. Other things I have preferences, but either way will be fine for me. Thanks for caring about this proposal, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
On Sat, Aug 07, 1999 at 12:57:21PM +0300, Antti-Juhani Kaijanaho wrote: On Fri, Aug 06, 1999 at 05:00:27PM -0700, Joel Klecker wrote: Well, I *need* that to represent glibc's source depends correctly. Do you? Yes, he does. It'd be rediculous for a Debian GNU/HURD system to need kernel-headers-2.2.10 to be installed for glibc's build depends to be satisfied, and equally rediculous for a Debian GNU/Linux system to need hurd-dev and gnumach-dev and mig(?). These packages share the common function of containing headers (?) for the kernel, be it Linux or the Hurd. Why is it then so appalling to have both package sets provide a suitable virtual package? (I will be easily converted to your ways if you just convince me of this point ;-) 1. Those packages do NOT provide the same functionality. The gnumach-dev and hurd-dev headers are quite different from the linux kernel headers. Thus, they don't fit under the same virtual package. Although you will notice that both connect the C library to the underlying kernel and multi servers, they are not interchangeable. It could well be that the Hurd header files will be made available under Linux some day, when people are interested porting some of its interfaces to Linux for applications. Then the virtual package provided will give completely the wrong idea about the package. 2. The mig package provides an *executable* that does not have any meaning under current Linux systems (except MkLinux probably). I can't see how you would fit mig into this virtual package scheme at all. To conclude, although I see a slight possibility why one could think of a virtual package kernel-header that is provided by both gnumach-dev and linux-kernel-headers, I don't see how this would solve the hurd-dev and mig dependency of libc on the Hurd, and I don't really see why libc would benefit from such a virtual package, as it would be necessarily meaningless (as no two kernels provide exactly the same interface). Furthermore, I wish you would not pin point this on the glibc package. I already told you that further packages will require this feature. Are you actually involved in any of our porting efforts? If not, it would be a healthy experience ;), or at least check one of the mailing lists frequently, to learn what is involved. Don't forget that Debian is not Linux anymore, just as it is not i386 anymore for a long time now. Here is another example: To build the Linux kernel on a i386, you need the bin86 package, on other platforms you don't. This may actually be solved by virtual packages, but it is a lot easier just to specify the correct architecture dependent source dependency. A further point: Of course, you can solve ALL architecture related dependencies problems by creating virtual dummy package. So, dummy-0, dummy-1 etc. Do you think this is an adequate solution to this problem? A very last point: Virtual packages require changes to multiple packages, while source dependencies are local to a single package. So, everything that helps keeping all relevant data inside the single package is very helpful in the development process. Are you converted now? :) Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
On Sat, Aug 07, 1999 at 12:57:21PM +0300, Antti-Juhani Kaijanaho wrote: On Fri, Aug 06, 1999 at 05:00:27PM -0700, Joel Klecker wrote: Well, I *need* that to represent glibc's source depends correctly. Do you? I know that I already responded, but this is important enough for me to pull all strings to kill the idea of using virtual packages for source dependencies to make sure you don't get any funny ideas about it. I'll bite and use the glibc package as a concrete example. But remember that there will be much worse packages, too. This is the situation: = Linux: glibc needs kernel-headers of a specific version. GNU: glibc needs gnumach-dev, hurd-dev, mig. = Now you suggested that we use a virtual package system-headers which glibc depends on. == Package: glibc Source-Depends: system-headers Linux: Package: kernel-headers Provides: system-headers GNU: Package: hurd-dev Provides: ? Package: gnumach-dev Provides: ? Package: mig Provides: ? === Things start to get ugly. How do you fill in the blanks below to make sure that all three packages are installed? Note that all three packages hurd-dev, gnumach-dev and mig don't have any dependencies on each other, and you shouldn't rely on indirect dependencies anyway. Note that if either of these Provides: system-headers, glibc's source-dependencies would be satisfied if only this package is installed, so we need either need a dummy package or three virtual packages: Solution A: == Package: glibc Source-Depends: system-headers Linux: (as above) GNU: Package: hurd-dev Provides: system-headers-1 Package: gnumach-dev Provides: system-headers-2 Package: mig Provides: system-build-utility # (what the HACK is THAT?) Package: system-headers (an empty package) Depends: system-headers-1, system-headers-2, system-build-utility === Solution B: === Package: glibc Source-Depends: system-headers-1, system-headers-2, system-build-utility Linux: Package: kernel-headers Provides: system-headers-1, system-headers-2, system-build-utility # ^^^ HUH??? GNU: (as Solution A, but without the empty system-headers package). == (You see, there are no names for the virtual packages that would make sense on BOTH architectures. Now imagine different source dependencies on three or four architectures!) Neither solution is acceptable. Changing the dependencies would involve action of several maintainers as well as the ftp archive maintainers (for creation and deletion of dummy packages). Furthermore, the concept of virtual packages is abused for a completely different matter, and does not provide an intuitive understanding of the dependencies. I don't object to use virtual packages where they are actually useful (for example, source-depends on awk if any awk is sufficient (mawk, gawk,...). But I think it is ridiculous to think that this will solve all problems. It is obvious that avoiding architecture specification in the source dependencies will simplify the proposal marginally at the very high costs for the maintainers. But the idea of the source dependencies is to make life for maintainers easier, not harder. If I have still not convinced everybody of the urgent need for arhcitecture specific build dependencies, I need to know which other solution could address the points raisen in this and prior mail. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
(Note: I wrote my second reply before polling my mail, so it is a bit out of sync to this mail :) On Sat, Aug 07, 1999 at 05:33:32PM +0300, Antti-Juhani Kaijanaho wrote: On Sat, Aug 07, 1999 at 04:08:56PM +0200, Marcus Brinkmann wrote: Are you actually involved in any of our porting efforts? No, as I don't have the required hardware. Then please trust the experience of porters like Joel, Roman and me in this one point at least. or at least check one of the mailing lists frequently, to learn what is involved. I lurk on several Hurd lists, including debian-hurd. Don't forget that Debian is not Linux anymore I'm not forgetting that. But there is another point of trying to make sure Debian is as same as possible in its all incarnations, in one release. This is another story. It is definitely something to consider for the user interface (same package management, same over-all design), but definitely not at system level. Especially not at the level where you compile parts of the low level operating system! Architecture-dependent build dependencies can lead into forgetting that goal. (Could we agree on a phrase in policy in the style of don't use the architecture-dependent build dependencies unless you really have to?) There are two things here. Of course, I don't want architecture specific dependencies where a bug or source incompatibility is preventing compilation of the package with a certain set of packages. But for additional features only some supported operating systems can provide I think it is a good idea to enable them and suck in further dependencies if required. For example, if a Hurd specific addition to the tar program (support for translators) would make it necessary to link tar with the hurd libraries, we need those libraries on the Hurd only. I can understand your concern of bad use of arch specific source dependencies, but I think I have two reasons why they won't be a big deal: . The porter and the maintainer are often different persons. This raises the barrier to add unnecessary source-dependencies and will make sure that more than two eyes watch over it. . In my experience, different source dependencies can hardly solve any incompatibility problems on the user level. Especially the first argument is very strong. Then, it is in everybodies interest that the source dependencies are clean. To answer your question: I think we can agree on such a phrase, but not in the way you said it. There is no need to discourage proper use of arch specific source dependencies. I am currently lacking some imagination. Can anybody come up with a good wording? Something like: General source dependencies are preferred over architecture specific dependencies. (to make it sound positive and not negative). However, as we can't specify *when* arch specific source dependencies are required, it doesn't matter much. I doubt that any such a phrase would have a huge impact on the way arch specific source dependencies can be used. But it does not harm to mention it either. So just do it :) Are you converted now? :) Possibly. I see your point and I trust that you wouldn't put this much effort to convince me if you didn't believe in what you're saying ;-) Definitely :) The real reason I am putting this pressure on you is that I am leaving for holidays next tuesday, and won't come back in the discussion time of this proposal. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
On Sat, Aug 07, 1999 at 11:31:16AM -0400, Chris Davis wrote: * If so, what syntax should we use? - My choice would be the package (= 42 i386) syntax, as it's the least intrusive choice. allright. But allow a seperator between version number and arch, like (= 42, i386) that's a bit easier on the mind. would (=42:i386) not be better so we could then also do something like (=42:i386, =44:alpha) In such a case, I would go for either of these: foo (=42, i386), foo (=44, alpha) or even foo (=44, i386, alpha) It is not necessary to complicate the syntax for this type of dependency. That foo is mentioned twice doesn't harm, IMHO. It makes it obvious that here is a problem to be fixed. This is probably one of those bad uses of arch specific source dependencies that Antti-Juhani was concerned about, and should be avoided. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Hi, On Thu, Aug 05, 1999 at 12:55:46PM -0700, Chris Waters wrote: And hey, when it comes down to it, this is just a proposal. My *primary* goal is to give the tech committee something else to consider if Manoj *does* send his proposal to them! :-) I think that with the number of seconds I've recieved (thanks guys!), this proposal is now too strong to ignore, even if it doesn't make it through the debates here. Which is really what I wanted. Formally object if you must -- I don't think it'll win you any friends, but it won't stop this proposal from filling *my* goals for it! :-) I am seeing a serious problem here. What bothers me is your this is just a proposal. A proposal should always be serious. Keep in mind that a proposal can actually become policy, and determine the direction of the distribution. That you consider your proposal primary as an alternative to be considered by a committee that only steps in if the policy group fails is also something that worries me a lot. The main intention of a proposal should be to provide a workable solution that ultimatively (after a discussion period) has support by the whole policy group. If people start filing proposals to achieve something else (and I am not going to second guess anybodies opinion, your statement above is clear enough in this context), we are doomed. Furthermore, you should not identify yourself with the proposal. The seconders did second your proposal. But it seems now their second is abused for the promotion of *your* goals whatever they may be. This tells me two things: First, that you are not standing behind your proposal as a solution for our distribution. Second, the rules Manoj made up for the policy group fail to work completely when people start to pay more attention to them than to the proposals themselves (see how you don't care at all about people probably objecting to your proposal). I am mildly disappointed, but I think this is part of our learning process. The next time a topic gets out of hand such as this one, people will hopefully realize this sooner and start to take a step back and think about what's happening here. Thanks, Marcus PS: Chris, please don't take this personally. You're not the only one to whom my critique is targetted. I do not exclude myself from the critique either. My formal objection to Manojs proposal for example was exactly the same playing with the rules I am talking about above. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: /usr/share/doc (was Re: weekly policy summary)
On Wed, Aug 04, 1999 at 01:05:13AM -0500, Manoj Srivastava wrote: Hi, Marcus == Marcus Brinkmann [EMAIL PROTECTED] writes: Marcus You're correct. The old prerm script is called before an Marcus update. This makes my analysis wrong indeed. The prerm Marcus scripts can go after the transition. I apologize for giving Marcus this wrong information. However, the fact that it took Marcus literally weeks for someone to correct me shows that only few Marcus people cared to think the proposal through completely, if Marcus anybody at all. I just can't let that pass. The reason no one corrected you is that you, and a few others, shot down the proposal, and there was no point flogging a dead horse. I admit that I left this process in disgust then, since people were more interested in power plays, apparently, than in discussing a solution. Mmmh. Anyway, even without you there would have been enough seconders to point out my mistake. It was not my intent to shot down the proposal under wrong assumptions (and it really surprised me how fast this happened), and I would have withdrawn my formal objection if someone had pointed out my mistake. I think formal objections should not take effect immediately. It can't be that we can shot down proposals within hours, when it takes at least two weeks of discussion to amend one. The way formal objections were treated this time, they appear to strong. Marcus Correct. I would like to see the proposal revived, with the Wold it not have been better to talk first, and shoot afterwards? At the moment, there is no provision for reviving proposals that have been killed by formal objections. Of course you are right, and I apologize. My only excuse is that we are all new to this. We have quite some experience with amending proposals now, but this is the first time objections played an important role. Maybe it is truely the case that this issue can not be handled rightfully within the policy group. Maybe it just took an unfortunate course. I don't know. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
On Mon, Aug 02, 1999 at 11:36:19AM +0200, Roman Hodek wrote: This shouldn't be too hard. You only need a syntax for it. There are several possibilities: Build-Depends: hurd-all:gnumach-dev, hurd-all:hurd-dev, linux-all:kernel-headers-2.0.36 The prefix idea is good, here a suggestion for concrete syntax: ARCH:packagerestricted to ARCH (all OSes) Your naming is weird ;) s/ARCH/CPU/, s/OS/SYSTEM/ and I'm your friend. An example would be a bootloader, by the way, like GRUB (a program with special grub support on i386 machines could exploit this). OS-*:packagerestricted to OS (all ARCHs) OS-ARCH:package restricted to OS-ARCH ARCH1|ARCH2:package more restrictions can be combined with '|', i.e. package restricted to ARCH1 or ARCH2 !ARCH:package restrictions can be negated with '!' Looks good to me. I don't know how many logical operators we should support, but it goes in the right direction. I am also unsure about the colon (:) as seperator. Build-Depends: texinfo Build-Depends-hurd-all: gnumach-dev, hurd-dev Build-Depends-linux-all: kernel-headers-2.0.36 This makes an inflation of field names :-) Agreed. I also think that the -Arch fields are overkill. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: /usr/share/doc (was Re: weekly policy summary)
On Fri, Jul 30, 1999 at 04:54:07PM +1000, Anthony Towns wrote: postinst install: ^^^ also at upgrade. if [ -d /usr/doc ]; then if [ ! -e /usr/doc/$package -a -d /usr/share/doc/$package ]; then ln -s /usr/share/doc/$package /usr/doc/$package fi fi prerm remove: ^^ also at upgrade. if [ -d /usr/doc ]; then if [ -L /usr/doc/$pakage ]; then rm -f /usr/doc/$foo fi fi This remains for woody (potato+1) at which point we file important bugs and remove packages that haven't been updated. Then for woody+1 we let people drop the scripts whenever they feel like. Crufty symlinks get removed when everyone updates to a new base-files that rm's symlinks from within /usr/doc in its postinst on upgrade, or something similar. There shall be no crufty symlinks whatsoever if everyone does do it right in the first place. Thus, partial upgrades to potato and woody have a complete /usr/doc, and full upgrades to woody have a complete /usr/share, and symlinks throughout /usr/doc. Partial upgrades to anything beyond woody might have old files left in /usr/doc, but they'll get moved when whoever finally gets around to run an apt-get dist-upgrade. Yes, this is correct. Anyway, I'm quoting Marcus Brinkmann from ~2000 new prerm/postrm scripts that must never go, even after the transition period. So this is definitely incorrect, yes? Yes, sorry. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: /usr/share/doc (was Re: weekly policy summary)
On Mon, Aug 02, 1999 at 10:57:12AM +1000, Anthony Towns wrote: On Sun, Aug 01, 1999 at 06:08:33PM +0200, Marcus Brinkmann wrote: On Sat, Jul 31, 1999 at 01:50:39AM +1000, Anthony Towns wrote: So all new packages will have to depend on this particular version of base-files or newer, or there is still no guarantee that the link gets removed. Erm, no, they don't need to declare any such dependency -- the package works with or without such a symlink. The package works, the removal won't. We will end up with a dangling symlink. No, the prerm removes the symlink, and the postinst reinstates it as necessary. The only problem is redundant symlinks when you're doing partial upgrades to woody+1 (or later), which no longer need any symlinks, from potato/woody. But they still all point at the correct places. You're correct. The old prerm script is called before an update. This makes my analysis wrong indeed. The prerm scripts can go after the transition. I apologize for giving this wrong information. However, the fact that it took literally weeks for someone to correct me shows that only few people cared to think the proposal through completely, if anybody at all. This proposal was suggested to make a smooth transition. If this smooth transition can't be provided without allowing downgrades and upgrades from any version to any other version it is not worth the bytes written with. If the correct solution can not be achieved without keeping a prerm script in every package forever, I consider the cost to be too high. So do I. But this is simply not the case. Correct. I would like to see the proposal revived, with the correct script snippets included, and a correct and complete analysis of what happens during upgrades (this is almost done already), downgrades(!), partial upgrades (also almost done), skipping of version numbers (this one is trivial) etc. If this is done, I will still not support the proposal (because I still think the cost is too high), but I will retract my objection. A precondition for this is that I am convinced by the proposal that all important cases are well covered. As there were a lot of supporters of the original proposal, I would be surprised if nobody steps up to make this work and creates example packages which use the script for some testing. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: /usr/share/doc (was Re: weekly policy summary)
On Sat, Jul 31, 1999 at 01:50:39AM +1000, Anthony Towns wrote: So all new packages will have to depend on this particular version of base-files or newer, or there is still no guarantee that the link gets removed. Erm, no, they don't need to declare any such dependency -- the package works with or without such a symlink. The package works, the removal won't. We will end up with a dangling symlink. Furthermore, the symlink will get removed as soon as (a) the user upgrades to a version of Debian that isn't meant to have the symlinks, or You mean a specific version of base-files, which is why we would need the dependency declared on it. (b) the user gets annoyed and gets rid of it him or herself. Oh, cool. Is this the solution you offer to this compatibility problem? 1000 symlinks dpkg doesn't know about in /usr/doc until I decide to upgrade to a package I don't know about (as a user) or until I am get annoyed and do it manually? You are making me even more suspicious of this proposal. I fail to see what the big problem with fairly obvious symlinks existing on a system that's halfway between two significantly different file system standards. I also can't see admins being particularly bothered by the existance of such symlinks on such systems. This proposal was suggested to make a smooth transition. If this smooth transition can't be provided without allowing downgrades and upgrades from any version to any other version it is not worth the bytes written with. If the correct solution can not be achieved without keeping a prerm script in every package forever, I consider the cost to be too high. But if you want to modify base-files, I think I am willing to let it happen. I don't consider the dependency on a special version of base-files to be too high a cost. Without the dependency in every package, I am strongly concerned about this proposal. We would get dozens of bug reports about the dangling symlink after removing a package. Don't you remember the removal problem of the base package? We got problem reports years after dropping it from the distribution. OTOH, it *is* inconvenient to have documentation scattered inconsistently between /usr/doc and /usr/share/doc. We've even had user complaints on this list about it. We will get a lot more complaints about a broken solution. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
On Sat, Jul 31, 1999 at 10:24:47PM -0700, Joey Hess wrote: on the grounds that it doesn't allow me to correctly specify glibc's source depends. I need them conditional on DEB_HOST_GNU_SYSTEM, e.g. for Linux-based GNU systems I need to depend on kernel-headers-version, for HURD-based GNU systems I need hurd-dev and gnumach-dev (at least, I think I do). I'm not sure how many other packages might need conditional source depends, this could be a specialized requirement. Why not make some virtual packages. All kernel-headers-* packages provide both, the hurd-dev and gnumach-dev packages each provide one. In my experience, such quick hacks are inconvenient for people who for example create a new distribution (for example Debian GNU/BSD), because changes need coordination between several maintainers. It is much better if we try to keep our decentralized structure. And, it would somehow be wrong, because there is no abstract ground on which these virtual packages could be created. They would come out of thin air, just to fit this proposal. We have packages that can't be compiled on all arhcitectures. Now we need to care about different source dependencies on different architectures as well. This shouldn't be too hard. You only need a syntax for it. There are several possibilities: Build-Depends: hurd-all:gnumach-dev, hurd-all:hurd-dev, linux-all:kernel-headers-2.0.36 Or: Build-Depends: texinfo Build-Depends-hurd-all: gnumach-dev, hurd-dev Build-Depends-linux-all: kernel-headers-2.0.36 Whatever you do, please make sure that this proposal is flexible enough to catch individual Debian architectures, not only Hurd vs. Linux. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
