Bug#191411: [proposal] build-depends-indep should not be satisfied during clean target
On Mon, Jun 09, 2003 at 10:59:18AM +0100, Julian Gilbey wrote: On Fri, Jun 06, 2003 at 06:31:31PM +0200, Bill Allombert wrote: I therefore propose the following change to section 7.6, which is a partial rollback from #164035: `Build-Depends-Indep', `Build-Conflicts-Indep' The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must be satisfied when any of the following targets is invoked: + `build', `build-indep', `binary' and `binary-indep'. - `build', `build-indep', `clean', `binary' and `binary-indep'. Seconded. Note that this policy change make a difference for arch: all source packages. For them, it is currently equivalent to use 'Build-Depends-Indep' and 'Build-Depends' With this change, it will no more be the case. Build-Depends will be safer since it cover clean (this trigger a lintian warning currently). Oh, bloody hell, lintian prods people into doing this? That's a bug. It can be worthwhile to state explicitly what happen for source arch:all packages in the policy. He's right. Lots of Arch: all packages (correctly) use Build-Depends-Indep and not Build-Depends at all. With this change to policy, almost all of them will immediately cease being policy compliant. (Most have debhelper as a dependency in the clean target.) Datum: they were never policy compliant until my earlier (botched) proposal. So what should this policy be? I understand the desire not to require Build-Depends-Indep to clean, but this isn't quite the way to do it properly. I say rip it out and return them to their buggy state. Since they've all had this bug for years, it's pretty clear that it's not all *that* important. However, regardless of what policy says, those packages are broken anyway. If you don't have debhelper installed, and you run dpkg-buildpackage -rfakeroot -us -uc -b, it'll fail. This bug is not important because there's no real reason to run that command on an arch-indep package. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpUZF4VJW06T.pgp Description: PGP signature
Bug#191411: [proposal] build-depends-indep should not be satisfied during clean target
On Mon, Jun 09, 2003 at 11:45:13AM +0100, Colin Watson wrote: He's right. Lots of Arch: all packages (correctly) use Build-Depends-Indep and not Build-Depends at all. With this change to policy, almost all of them will immediately cease being policy compliant. (Most have debhelper as a dependency in the clean target.) So what should this policy be? I understand the desire not to require Build-Depends-Indep to clean, but this isn't quite the way to do it properly. Any ideas? How about something that conveys the following intent: * If a package has only Build-Depends:, or both Build-Depends: and Build-Depends-Indep:, then Build-Depends: must be satisfied for clean. * If a package has only Build-Depends-Indep:, then Build-Depends-Indep: must be satisfied for clean. It's less elegant by some way, but does seem to be roughly what people want and still compatible. Does it have any downsides? If you take a regular Arch: any package that has an Arch: all component, and both the arch-dep part and the clean target have no build-dependencies, things get complicated. You'd want an empty Build-Depends: field, which has a non-obvious meaning and may confuse some tools. Plus it's not what the tools currently implement. Alternatively, we could just special-case source packages that only generate Architecture: all binaries and say that they need to satisfy Build-Depends-Indep: for clean. So: `Build-Depends-Indep', `Build-Conflicts-Indep' The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must be satisfied when any of the following targets is invoked: `build', `build-indep', `binary' and `binary-indep'. In addition, if the source package only generates `Architecture: all' binary packages, they must be satisfied when the `clean' target is invoked. This is probably better, since it doesn't change anything that currently works... but do we really want to do that? Note, both of these will require changing dpkg-dev, and may cause difficulties building new source packages on older releases. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpXEQTUqn6hS.pgp Description: PGP signature
Re: Status of UTF-8 Debian changelogs
On Sun, 08 Jun 2003, Wouter Verhelst wrote: [EMAIL PROTECTED]:~$ echo $LANG nl_BE.UTF-8 Is it in locale.gen? Otherwise, you will NOT have the locale information... which means that uxterm manually ensures that $LANG is set to something.UTF-8, since I set my $LANG to nl_BE. Ick. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Status of UTF-8 Debian changelogs
On Mon, 2003-06-09 at 12:05, Henrique de Moraes Holschuh wrote: On Sun, 08 Jun 2003, Wouter Verhelst wrote: [EMAIL PROTECTED]:~$ echo $LANG nl_BE.UTF-8 Is it in locale.gen? Otherwise, you will NOT have the locale information... Ah, good call. We should have that in the default locale.gen.
Bug#191411: [proposal] build-depends-indep should not be satisfied during clean target
On Mon, Jun 09, 2003 at 10:59:18AM +0100, Julian Gilbey wrote: It can be worthwhile to state explicitly what happen for source arch:all packages in the policy. He's right. Lots of Arch: all packages (correctly) use Build-Depends-Indep and not Build-Depends at all. With this change to policy, almost all of them will immediately cease being policy compliant. (Most have debhelper as a dependency in the clean target.) So what should this policy be? I understand the desire not to require Build-Depends-Indep to clean, but this isn't quite the way to do it properly. Any ideas? It's important to note the context here, I'd say. The reason for the build-depends vs build-depends-indep split is so that autobuilders don't waste too much time (un)installing stuff they won't need in the end, it's not for statistical reasons or anything like that. One could put everything in Build-Depends, and still be policy compliant. If this detail (which it really is) is important, that should be taken care of, too. For the time being, it is IMHO better we just make sure that automated builds don't fail because it's policy compliant to do something which happens not to be implemented that way. I most certainly agree that it's possible to specify more detailed build-depends, which would make sure the package builds in all possible and impossible situation we could think of, but that's not why Debian needs build-time dependencies. We need it to make sure our users can build packages (which they usually will do by doing something like 'apt-get -b source foo', which builds all packages, not just the binary-indep ones) and for our autobuilders to function correctly (for which this amendment will make sure everything works; I've seen people using build-depends-indep on packages with both binary-arch and binary-indep targets, where the clean target needed one of the build-dependencies). Policy currently explicitely says that people doing builds of only the architecture-independent packages are assumed to know what they're doing. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpApvB78TSJk.pgp Description: PGP signature
Re: Status of UTF-8 Debian changelogs
Hi Colin! On Mon, 09 Jun 2003, Colin Walters wrote: On Mon, 2003-06-09 at 12:05, Henrique de Moraes Holschuh wrote: On Sun, 08 Jun 2003, Wouter Verhelst wrote: [EMAIL PROTECTED]:~$ echo $LANG nl_BE.UTF-8 Is it in locale.gen? Otherwise, you will NOT have the locale information... Ah, good call. We should have that in the default locale.gen. You'd need to add UTF8 locales for every locale, then. And they're often unsupported. I know for a fact pt_BR.UTF8 is unsupported (even if localegen claim it managed to generate it). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Bug#58355: Are you smoker? You can save money on tobacco!
Title: Are you smoker? You can save money on tobacco! Are you smoker? We are proud to invite You to new Tobacco Shop http://www.megatobacco.com. We have special prices at discounts and free shipping as our gift for our customers. We have more than 100 of marks of cigarettes from Marlboro, Camel and other are available. We shall be very grateful to You for visiting http://www.megatobacco.com and sending Your suggestions and questions about our shop. Sincerely YoursMegaTobacco.com Team For unsubscribe reply this email with subject 'Remove' LyepRhwwlVzatrKugA
