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 "-linux" instead of "-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: 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 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: 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 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 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: 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]
Bug#137172: removing Dan Quinlan's addr from policy
On Thu, Mar 14, 2002 at 12:02:00AM -0800, Chris Waters wrote: > Hi, this doesn't seem to be moving forward. There's only one second. > We either need a second second (as it were), or we need some policy > editor to decide that a change of this nature doesn't require seconds > (a more reasonable approach IMO), and just to fix it. ok. I decide that you (or whoever can) should go and do that change. 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 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: 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: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: 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
Bug#111839: PROPOSAL]: packages should be cross buildable
On Sun, Sep 09, 2001 at 11:27:36PM -0700, David Kimdon wrote: > + > +ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) > +# commands and/or variables for cross build > +else > +# commands and/or variables for native build > +endif > + This is half correct :) I suggest to just refer to dpkg-architecture(1), as the technical details may change. In particular, you should not use the variables without initializing them DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) etc In general, I support a proposal that encourages cross compilation. I am not sure about the wording, and how much technical details it should contain. (But I can't make a better suggestion right now). 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: 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: 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 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 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 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 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
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
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 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
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] disallow multi-distribution uploads
On Thu, Mar 22, 2001 at 09:00:02PM +1100, Herbert Xu wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > > > > IMHO, the fundamental and unavoidable reason why we have this problem > > is the following: > > > We don't know in which Packages files (=distributions) a > > single binary is (used or) going to be used. > > Perhaps I'm missing something, but I thought the whole point of having all > these dependencies is so that as long as all of them are satisfied, that > the package continues to work. If that's not the case, I think we better > pack up and go home :) Well, yes. If you leave aside that the dependencies don't always tell the whole truth, the point is that the dependencies can be different depending on your build environment (considering libraries). I think one point for testing to wait for a widely available version is to not have entirely different trees because of different libraries. This is one of Bens points in disguise (maybe my whole argument was just the generalization of Bens others points). If you compile on unstable for "stable unstable", you might suck in newer libraries. If you compile on stable, you might stick with older libraries even on unstable. The package depends on the build environment (not only in its dependencies, but probably also in file locations etc), and we need to choose the build environment depending on the distributions the package is going to be used on (or not). In all its generality, this is a difficult problem. But for packages like your kernel packages, this is of no concern. So if we stick with the possibility "stable unstable" for packages where the *build environment* can be either a stable or unstable machine, and where the resulting packages are fine in stable (wrt stability) and unstable (wrt cutting the edge), then I think this is perfectly ok. I am now realizing that I am making a new point here, and I have to think about it, but it seems that this could probably mean that we have to look at the (factual) build dependencies. To summarize: I see no problem with allowing "stable unstable" uploads for packages which work the same regardless where they are built on (this includes version of debhelper, libraries etc). This seems to be a quite strict requirement, stricter than it used to be, I think. > > This is a source for conflicts and inconsistencies, because whenever you > > want to compile something you have to make sure it will be okay for all > > distributions it is going to be used in. As this includes decisions made in > > the future[1], there are potential problems you can't address. > > Well my position is that the people in future should make accomodations for > you. This is what compatibility is all about. If a library changes its > ABI, then it must change its soname (or at least their package name) so it > doesn't break old binaries. Other things should also act accordingly. There are more subtle problems here than library apis. For example, I had a package which could be built on stable, but not on unstable, because the behaviour of strip changed. Or debhelper installed docs into the new place and a hard coded path in the rules files broke. If all these are considered, I agree with you. But as I said above, this issue has a strong relation to build environments and build dependencies. 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 12:42:57PM +1100, Herbert Xu wrote: > Well my point is that disallowing "stable unstable" doesn't solve those > problems for most packages, as "stable unstable" uploads are rare to start > with. And for packages which don't have these problems, this incurs > significant overhead on the part of the maintainer. There are indeed some packages were it doesn't matter where you build it, and where the interfaces don't change between Debian revisions. I think the cases are few, but there is no need to burden the maintainers in those cases, even when Bens proposal gets accepted. I suggest for these cases that the upload is done for unstable (only), and a bug report is filed against ftp.debian.org or some other suitable virtual package (for example "stable-releases"), requesting inclusion into stable. This is not a lot of work. The release manager needs to look at this place of course, instead in the upload queue. It's just a matter of how to communicate it to the release manager. Do you think this is a workable compromise? 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] disallow multi-distribution uploads
On Tue, Mar 20, 2001 at 11:06:02PM -0500, Ben Collins wrote: > It's my opinion that same version uploads to stable/unstable are harful > to archive and distribution integrity. There is a deep reason why this makes sense, but I think you didn't mention it explicitely. The reasons you mentioned are practical, but not critical. The critique is justified, because if it *does* matter if you compile on stable or unstable it should not say "stable unstable" in the changelog. (In practice, the set of such package is small for the reasons you mentioned rightfully). IMHO, the fundamental and unavoidable reason why we have this problem is the following: We don't know in which Packages files (=distributions) a single binary is (used or) going to be used. This is a source for conflicts and inconsistencies, because whenever you want to compile something you have to make sure it will be okay for all distributions it is going to be used in. As this includes decisions made in the future[1], there are potential problems you can't address. The testing area faces this problem as well. It was solved partially by deciding that a package only enters the testing distributions if it was available on all to-be-released architectures. This provides some amount of consistency: You knew that the same version of a package was used in all released architectures (not too unimportant if you consider binary-all packages). This partially addresses the cross-architecture problem. The orthogonal problem is not solved: cross-releases. We had no solution for this in the past[1], we don't have a solution for this, and your proposal solves this by eliminating "merged parts of the branches". After the release, we split off and keep updates distinct. It is a rough decision, but it is workable. To solve the generic problem, we would need an entirely different mechanism to keep track of distributions a package currently belongs to and develop various strategies what to do with packages belonging to various groups. (You mentioned some, like compiling for stable and uploading to both). It is really an interesting problem, but too hard to solve in its generality, I am afraid [2]. Restricting the possible cases with proposals like yours is very reasonable. In fact, what you propose has the effect of seperating the source archives for unstable and stable (without duplicating identical sources). It's like a split off of the pool at release time (but without performing the actual split physically). Semantically, it seems to be the right thing to do. I think I support your proposal, but I haven't read the exact wording very thoroughly yet. Thanks, Marcus [1] You can upload to stable and unstable, but you don't know if it will really be accepted for stable. You can upload to unstable, and you don't know if or when it will reach testing. [2] I have not thought this through. I have thought about it a bit, and the amount of possible cases is stunning. In fact, potentially unlimited. -- `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 /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. 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: All services that require a restart from libc6 upgrade...
On Mon, Oct 16, 2000 at 06:39:02PM -0300, NicolƔs Lichtmaier wrote: > > Ok, I'm tired of having to track all services that might need to be > > restarted after a libc6 upgrade. So here's what I am going to do. I want > > to require all packages that need this to declare a new reply in it's init > > script. It's very simple, I check your init script like this: > > Is it posible to detect if the service needs a restart by examining the > executable file? > > E.g.: > objdump -T $( readlink -f /proc/$PID/exe ) | egrep 'symbol1|symbol2' > > The processes to restart could be taken from ps AND /etc/init.d/*. This only works under Linux (/proc usage). 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: Preparing Debian for using capabilities: file ownership.
On Thu, Sep 21, 2000 at 09:57:34PM +1100, Brendan O'Dea wrote: > On Thu, Sep 21, 2000 at 01:43:52AM -0700, Joey Hess wrote: > >NicolƔs Lichtmaier wrote: > >> It should be: > >> > >> -rwxr-xr-x1 bin bin 42300 jul 29 13:26 /bin/ls* > >> > >Using an existing group like bin could cause problems. It's possible > >systems exist that have users in the bin group and don't expect them to > >suddenly be able to edit every file on the system. (What is the bin > >group used for now, anyway? Only 3 files on my system are owned by it.) We > >should probably make a new group if we do this. > > That's three more than on mine, > > find / \( -user bin -o -group bin \) -ls > > produces zip. Don't forget that joeyh has the biggest harddrive of the world. He must have, because he has a maximum number of Debian packages installed. (Joey, what is the maximum number of Debian packages you can install without having a conflict?) 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]
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]
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: > > 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 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 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 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 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 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 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
Bug#53762: PROPOSED] applying the FHS to packages that use X
On Tue, Jan 11, 2000 at 03:21:36PM +, Julian Gilbey wrote: > I like this! (Read: seconded) At long last, we may be able to do > away with the regular /usr/X11R6/bin vs. /usr/bin debate! Seconded as well. At one time we will be able to drop /usr/X11R6. (I am certain that this will happen at least on the Hurd, when we have shadowfs and the possibility to install concurrent versions of the same package, customizable per user). Marcus
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: Thoughts about src-dep implementation
On Fri, Oct 29, 1999 at 08:27:01AM -0400, Ben Collins wrote: > > The problem comes for the actual maintainer who wishes to update the > source deps (and doesn't always use a .dsc, since he is just building a > new package). The Build-* stuff should come from the debian/control file > /after the package is built, but before the source tree is cleaned/. I think I am confused. About which situaton are we talking now? Maybe there are two cases we consider: 1. A user gets a source package and wants to check the dependencies after unpacking but before compiling. 2. A maintainer builds a package, and wants to get the source deps into the dsc file. In the first case, the *.dsc file is quite sufficient. You just have to keep it around. The "random files cluttering up the dirs" is not justified, IMHO, as the alternative (copying the information somewhere in the build directory) is not more appealing to me: It seems to be more obscure and overly complicated, and unnecessary as the information is there in a well defined place: If you choose to ignore it and delete the file (or not copying it in the first place), you declare that you checked the depends and don't need them anymore. This is different from what you seem to mean above, in which case there doesn't necessarily exists a dsc file, and it should not be used. Instead, the information should come from the control file. To support autogeneration, the information should be considered to be complete only after the package build. Is this what you mean? 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 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
Hi, On Wed, Oct 27, 1999 at 02:46:45PM +0200, Roman Hodek wrote: > > - dpkg-source extracts the Build-* fields from the .dsc and writes >them to debian/build-depends. Sounds a bit too much like magic for me. It should not be necessary to make such wiggles to build a package succesfully. By all means make this optional. Working from the dsc is fine for me, for example. Your argumentation shows probably that there is a flaw in how the dsc file is handled. Instead hacking around symptoms, we should reconsider the whole setup and seek for a clean solution (with clean I mean something that not only works, but has some aesthetic and conceptual merit :) > - We extract some parts from sbuild and make a new script >dpkg-check-srcdeps from them. dpkg-buildpackage can call this >script if this is requested (or not inhibited), and can abort if >there are any errors. Also sbuild will use dpkg-check-srcdeps so >that the code isn't doubled. 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. >Until all packages come with src-deps, it's still necessary that >the checker script is able to read /etc/source-dependencies >(representing the current central database), but this can be a >seperate option used only by sbuild. I think we'll also need some >kind of override file, but this, too, can be an option. All of this does not belong in the standard setup, IMHO. > - IMHO it's still a goal that parts of the source dependencies should >be auto-generated, for two reasons: 1) it saves some work for the >maintainer (he doesn't have to write down lots of -dev packages), >and 2) will avoid lots of errors. If we don't have that >auto-generation, it will be easy to forget that one has upgraded >some lib+dev packages, and therefore src-deps might have to change. This can be an entirely independent project, too. >The problem with this: Currently the .dsc is built before >compiling, and thus the Build-* fields have to be known before >dpkg-shlibdeps is run. But there's an easy solution (IMHO): Why >don't we build the source package after the binaries? This would >speed up the development cycle anyway, because as long as you're >experimenting you currently often build the src package >unnecessarily. Also, you automatically have cleaned source trees >after dpkg-buildpackage, which can save some disk space if you >maintain lots of packages :-) At least I can't see now big problems >if dpkg-buildpackage runs "debian/rules clean; dpkg-source -b" >after building the binaries. Comments? All my object files with debugging symbols would be lost !!! This is not a good idea. To me it shows that trying to be overly clever with automagically depends generation backfires too easily. Well, all IMNSHO, 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: 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-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]
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]
Bug#46516: PROPOSAL] MIME support sub-policy
On Sat, Oct 02, 1999 at 06:51:44PM +0200, J.H.M. Dassen Ray" wrote: > + > + 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 ftp.debian.org in > + /debian/doc/package-developer/mime_policy.txt > + or your local mirror. > + 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: 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/
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: 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) - Note that all installed binaries should be stripped, + Note that by default all installed binaries should be stripped, either by using the -s flag to install, or by calling strip on the binaries after they have been copied into @@ -1980,16 +1980,35 @@ package. - The -g 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. - - The -N 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. - + + + It is recommended to support building the package with + debugging information through the following interface: + If the environment variable DEB_BUILD_OPTIONS + contains the string debug, compile the software with + debugging information (usually this involves adding the + -g flag to CFLAGS). This allows to generate + a build tree with debugging information. If the environment + variable DEB_BUILD_OPTIONS contains the + string nostrip, 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: + + + CFLAGS = -O2 -Wall + INSTALL = install + ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) + CFLAGS += -g + endif + ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) + INSTALL += -s + endif + + 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: 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/
Re: Bug#43787: changed title, and remade the proposed change
On Thu, Sep 09, 1999 at 05:06:32PM -0400, Raul Miller wrote: > > Personally, I'd recommend defining DEB_DEBUG_OPTION=debug-strip which > would build with debugging symbols, but strip for package generation > then strip. Mmh. I see your point. What about having "debug" and "strip"? This would allow for: DEB_DEBUG_OPTION=debug nostrip # Build debug packages. DEB_DEBUG_OPTION=debug # Build debug files, but strip them in package. This means, stripping is default. > This alone would address most of (a) and (b). The only > options I can think of for (c) are: don't use =debug or somehow rename > the package at build time. In case of (c), I would say the above suggestion (strip being default), addresses it. OTOH, we never can prevent random errors/failure conditions. 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: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: Bug#43787: changed title, and remade the proposed change
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. >The main point being, that most developers _want_ to be standard >and will not want to go the extra mile of implementing something >completely different than policy suggests that wont get used. Then we can make it mandatory just as well. > 2) Perhaps there is no way for that maintainers package to comply >exactly with the details of the requirement. 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. >Also there may be different cases of what debugging actually is in >a package. Perhaps it is a set of scripts, that when generated normally >strips out some of the debug code, but can also be generated with the >debug code. We don't know, so we can't force this. You are missing my point. My concerns are only about the interface, not under which circumstances the support should be implemented (we all want it to happen in as many cases as possible), and not about the way it is implemented (CFLAGS=-g, or whatever). > This proposal has clear advantages (as others have admitted) In my eyes, it has not an advantage, but disadvantages. First, we will probably get less support for building with debugging info because it is not the default anymore and adding the interface is not encouraged anymore. This will give a small compile time increase at the cost of making it harder for users to get packages with debug information. I wthdraw my second. I don't object to your proposal, although I find it suboptimal at least. Instead, I'll probably raise another proposal somewhat later. Obviously, in the current atmosphere here I can't get my point across. > Fortunately, this one will > atleast be able to back out easily because it is non-obtrusive to how we > currently > do things (we still get stripped packages without changes). Oh how great. This is really a great proposal of you, that accomplishes such a difficult goal. Marcus -- `Lack of ambition is a sin.' 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
Hi, On Wed, Sep 08, 1999 at 09:24:06PM -0400, Raul Miller wrote: > On Thu, Sep 09, 1999 at 02:19:36AM +0200, Marcus Brinkmann wrote: > > 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. > > I think I could build you a package which does this for you in a couple > hours. However it would be a hack, and it might (or might not) be a > problem in an autobuilder environment that needed to support multiple > compilers -- depending on exactly how that environment was architected. Yes, of course. But as you said, it would be a hack. It would require installation of a wrapper package although all the needed functionality is there (just no well defined interface to activate it and support for the interface in the package). > > 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. > > Ok. If we want to have this as a goal then yeah: Ben's proposal doesn't > meet this goal. Yes, this is probably beyond Bens proposal, and needs to be developed seperately. But in this case Ben should not make suggestions about the interface in his proposal, IMO. > > I hpoe my point is now more clear. > > I think so: > > To achieve this goal, you really want two things to happen: > > (1) You want a way to guarantee that elf executables are built with > debugging symbols. [Depreciating the current possibility that they > wouldn't be.] Minor correction: Only if it is supported. I can think of some upstream software which does not support this very well or at all. However, if it can be supported, it should be, and if it is supported, it must be supported through a well defined and extensible interface. Bug reports which implement this feature should be accepted (if the patches are of acceptable quality of course). > (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). > Since Ben's proposal only touches on compilation -- not package building > or installation -- you're only addressing (1) at the moment. > > Do I have this correct? Yes. > [And, do you think there'd be a problem waiting on (1) until (2) is > being addressed?] Ah yes. Thanks for reminding me of (2). It is indeed true that it is not adresses at all yet. Mmh. Okay, I take a step back now in this thread. But Ben should probably take out the interface suggestion until we have thought about it a bit longer. Raul, do you have any ideas about a clean interface? What's better than a DEB_BUILD_OPTIONS variable in your view? 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
Raul Miller wrote: > > On Wed, Sep 08, 1999 at 02:52:59PM +0200, Marcus Brinkmann wrote: > > 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. > > No. > > You can always build with DEB_DEBUG_OPTIONS=debug and expect that the > executables created will have debug symbols. This is already true even > without this policy being implemented. This is true now, but with the proposal of Ben implemented, we have the following sentence: > 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 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). This is what I am concerned about. Either we write down a standard way in policy and make it mandatory (for packages which support it), or we forget about it. Am I missing something? Thanks, Marcus
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: 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: 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 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/
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: 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/
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 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: [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: /usr/doc transition and other things
On Mon, Aug 30, 1999 at 02:43:32PM -0400, Raul Miller wrote: > Basically, yes. But, wishes are intangible... That there are something > like 2000 packages out there which haven't implemented /usr/share/doc/ > should have been sufficient clue. Joey Hess did chose not to implement this change yet as he waited for a consensus on the discussion that started about this topic. This rules out 70% of our packages, which are based on debhelper (figure may be wrong, but approx.). Many people hesitated because of the discussion on this list. Our project leader explicitely asked not ot make the change currently in the Debian weekly news. I do not think that the sole fact that many people did not make the move yet is an argument one way or the other. If it will be argued this way, I shall convert my packages to /usr/share/doc immediately. 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: /usr/doc transition and other things
ore sense this time? *vaguely hopeful look* Yes, I think we are at the heart of our diasgreement. I also see your point, but still I prefer it the other way *blink* ;) The Debian policy is an "idol". We should always try to reach compliance, but we should not "turn it down" because we can't comply. Of course, modesty is also a nice thing. It just doesn't carry you very far, IMHO. The danger is that the time you want to make the final change gets delayed over and over again. > Can you agree that having policy say "You can do either or , > but we'd prefer " is better than having policy say "You must do > ", but telling everyone that it's not important that you change from > to 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 or , but we'd prefer " is worse than "You must do , 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 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