Bug#620566: dpkg: version number does not start with digit is in contrast to policy
On Mon, 4 Apr 2011, Carsten Hey wrote: upstream_version git1234 could be prefixed with epoch 0 and thus lead to the version number 0:git1234-debian_revision. Maybe this could be Nah. Just drop the leading 'git'. On Mon, 4 Apr 2011, Raphael Hertzog wrote: We have no upstream with such versions currently in Debian. I don't really We have, mksh version numbers are mangled (see its watch file) in a defined way. It uses a repacked source as .orig.tar.gz, but since dpkg’s extraction mechanism doesn’t really care, for a package with a normal tar.gz upstream this wouldn’t even matter. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die! -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1104081424520.7...@tglase.bonn.tarent.de
Re: Patch for MultiarchCross
Steve Langasek vor...@debian.org writes: Hi there, On Wed, Mar 23, 2011 at 03:05:53AM +, Wookey wrote: The Multiarch specification only covers libraries and does not specifically deal with include files. To make multiarch useful for cross-building as well as co-installation of libraries we need to install headers to /usr/include/triplet, which needs an FHS exception. Maybe we should stop calling it triplet since it isn't the gnu triplet anymore (at least for some cases)? Here is a patch to policy to allow that. It could repeat most of the libraries section above but there seemed little point. I'm happy to expand it though if we think that would be helpful. I'm not sure if anything else in policy needs to be adjusted - I didn't see anything obvious. The only thing I wonder is whether we should go farther yet and make this a policy recommendation rather than just granting permission... but since we're only just now implementing toolchain support for this, I guess that might be premature. I would make this a recommendation but only for include files that differ between architectures and for any package that uses multiarch paths. Those packages already need the Pre-Depends on the multiarch package. The multiarch package must then ensure not only that the ld.so works with multiarch paths but also that a suitable toolchain is used (Break on unsuitable toolchain packages, not depends). What we don't want is every library package deciding on their own solution on where to put files and many long -I ... options or gcc not finding the files. What could be allowed is using the new include paths with a Depends on the multiarch package even if the package itself is not multiarch. I would file this as a bug against debian-policy but I don't know whether it should be normative, informative, etc. Advice welcome. Reading the FHS carefully, I see that there is no requirement for headers to be installed *directly* under /usr/include, only that they be installed *somewhere* under this directory. And indeed, many packages create subdirectories under /usr/include already. So maybe it's not actually needed to override the FHS at all for /usr/include, until the time that we want to make this a policy recommendation? I.e., I guess this isn't a normative bug because we're not actually changing any rules; and it's not really informative either because we're not actually providing much information yet. :) Do you think there is a specific recommendation policy should make right now, or should we defer amending policy until the prelim implementation is farther along in unstable? MfG Goswin -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwpsk58k.fsf@frosties.localnet
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
Raphael Hertzog hert...@debian.org writes: On Sun, 03 Apr 2011, Russ Allbery wrote: My inclination is to second this, but I want to make sure that we've answered your and Julien's objections first. And for complete reference, dpkg accepts those version in /var/lib/dpkg/status (so that dpkg still works for users with affected packages installed) but will not a accept to install a .deb with a bad version anymore. Cheers, It does not allow them in available though breaking many systems that have or in the past had a package with such a version available. At least 4 people on irc have run into that problem that I saw already. MfG Goswin -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp0gk54b.fsf@frosties.localnet
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
On Fri, 08 Apr 2011, Goswin von Brederlow wrote: It does not allow them in available though breaking many systems that have or in the past had a package with such a version available. At least 4 people on irc have run into that problem that I saw already. It does allow them in available. Those people are confused or affected by something else. They might not know how to get rid of the warnings though (dpkg --clear-avail). Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110408183316.ga10...@rivendell.home.ouaza.com
Re: Patch for MultiarchCross
On Fri, Apr 08, 2011 at 07:44:27PM +0200, Goswin von Brederlow wrote: On Wed, Mar 23, 2011 at 03:05:53AM +, Wookey wrote: The Multiarch specification only covers libraries and does not specifically deal with include files. To make multiarch useful for cross-building as well as co-installation of libraries we need to install headers to /usr/include/triplet, which needs an FHS exception. Maybe we should stop calling it triplet since it isn't the gnu triplet anymore (at least for some cases)? It is still a GNU triplet; it's just not the same as the host triplet for the architecture in select cases. What could be allowed is using the new include paths with a Depends on the multiarch package even if the package itself is not multiarch. No. multiarch-support declares runtime support for ld.so. It has nothing to do with include paths (or -dev packages in general) and should not be abused like this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Patch for MultiarchCross
On Sat, Apr 02, 2011 at 01:14:28AM -0700, Steve Langasek wrote: Hi there, On Wed, Mar 23, 2011 at 03:05:53AM +, Wookey wrote: The Multiarch specification only covers libraries and does not specifically deal with include files. To make multiarch useful for cross-building as well as co-installation of libraries we need to install headers to /usr/include/triplet, which needs an FHS exception. Here is a patch to policy to allow that. It could repeat most of the libraries section above but there seemed little point. I'm happy to expand it though if we think that would be helpful. I'm not sure if anything else in policy needs to be adjusted - I didn't see anything obvious. The only thing I wonder is whether we should go farther yet and make this a policy recommendation rather than just granting permission... but since we're only just now implementing toolchain support for this, I guess that might be premature. I would file this as a bug against debian-policy but I don't know whether it should be normative, informative, etc. Advice welcome. Reading the FHS carefully, I see that there is no requirement for headers to be installed *directly* under /usr/include, only that they be installed *somewhere* under this directory. And indeed, many packages create subdirectories under /usr/include already. So maybe it's not actually needed to override the FHS at all for /usr/include, until the time that we want to make this a policy recommendation? I.e., I guess this isn't a normative bug because we're not actually changing any rules; and it's not really informative either because we're not actually providing much information yet. :) Do you think there is a specific recommendation policy should make right now, or should we defer amending policy until the prelim implementation is farther along in unstable? I already made this comment, but I strongly think it should be normative. Specifically we should mandate that: 1) /usr/include/triplet be added to the default hearder search path of triplet-gcc. 2) Packages that would install headers in /usr/include/path install them in /usr/include/triplet/path Libraries sometimes provide public headers in sudirectories of /usr/include, but their documented states that C files should do #include path/header.h instead of #include header.h Requiring the user to pass -I to the compiler should be discouraged. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. signature.asc Description: Digital signature
Gratis por TIEMPO LIMITADO
4/8/2011 16:45:36 Todo propietario de un sitio web sabe que conseguir visitantes para el mismo es una tarea dura, y difícil, pero importantísima. El estar bien ubicado en los buscadores es una parte fundamental de la promoción de cualquier sitio web. Debido a que pensamos que el tema puede ser de su interés es que le enviamos a debian-policy@lists.debian.org este ofrecimiento por tiempo limitado Hoy en día hay tantas opciones para promover un sitio web en internet, que para quien es novato en el tema, pueden crearse confusiones y desconciertos. Muchos se preguntan qué opciones elegir, un alta en buscadores, un intercambio de links, alquilar banners, un resultado patrocinado, las variantes son muchas cada una con su ventaja y su desventaja. Por esa razón, y para asesorar a nuestros clientes hemos creado un curso gratuito de 12 lecciones que le enseña al propietario de un sitio web las mejores opciones para promover su sitio mediante los buscadores de internet. Este curso se diseñó originalmente en forma exclusiva para nuestros clientes, pero en esta ocasión, y por tiempo limitado, le damos a usted la posibilidad de tomarlo, es totalmente gratuito. Este curso consta de 12 lecciones, que le serán enviadas por e-mail, una al día. Cada lección trata en un lenguaje ameno y simple, un tema en particular. Este curso NO le enseñará a dar de alta en buscadores, sino que SI le enseñará sobre las diversas opciones actualmente disponibles en el mercado de promoción mediante internet, y le explicará cómo lograr que su sitio web sea amigable a los ojos de los buscadores Si usted está interesado en aprovechar al máximo las opciones que le dan los diferentes métodos de promoción en internet, en especial el alta en buscadores, sus variantes, y sus complementos, no puede dejar pasar esta oportunidad. Cupo limitado a los 100 primeros suscriptos. Para suscribirse al curso envíe un e-mail en blanco a la casilla de correo curso.espec...@rocketmail.com MUY IMPORTANTE PARA QUE LA SUSCRIPCIÓN AL CURSO SEA EXITOSA DEBE COLOCAR EN EL ASUNTO DEL E-MAIL QUE ENVÍA LA PALABRA SUSCRIBIR. Esto es muy importante, ya que si no coloca la palabra SUSCRIBIR en el asunto o subjet del e-mail que envía no recibirá el curso. Si conoce a alguien que esté interesado en este tema, por favor reenvíele este e-mail. Gracias TC -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110408164536.2c16d5ef2865e...@telecentro.com.ar
Re: Patch for MultiarchCross
Steve Langasek vor...@debian.org writes: On Fri, Apr 08, 2011 at 07:44:27PM +0200, Goswin von Brederlow wrote: On Wed, Mar 23, 2011 at 03:05:53AM +, Wookey wrote: The Multiarch specification only covers libraries and does not specifically deal with include files. To make multiarch useful for cross-building as well as co-installation of libraries we need to install headers to /usr/include/triplet, which needs an FHS exception. Maybe we should stop calling it triplet since it isn't the gnu triplet anymore (at least for some cases)? It is still a GNU triplet; it's just not the same as the host triplet for the architecture in select cases. What could be allowed is using the new include paths with a Depends on the multiarch package even if the package itself is not multiarch. No. multiarch-support declares runtime support for ld.so. It has nothing to do with include paths (or -dev packages in general) and should not be abused like this. Will there be a multiarch-dev-support then or will -dev packages have to Depends on the right versions of a number of build tools? MfG Goswin -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrj4lcq7.fsf@frosties.localnet
Re: Patch for MultiarchCross
On Fri, 08 Apr 2011 at 21:51:03 +0200, Bill Allombert wrote: Requiring the user to pass -I to the compiler should be discouraged. I disagree: independently of multiarch, many libraries do this deliberately to allow for parallel-installation, and use pkg-config to give out appropriate CFLAGS. For instance, you can have libgtk2.0-dev and libgtk-3-dev installed at the same time, even though they both include (for instance) gtk/gtkwindow.h; using -I/usr/include/gtk-2.0 or -I/usr/include/gtk-3.0 (or in practice, asking pkg-config for gtk+-2.0.pc or gtk+-3.0.pc) selects the desired API. Requiring all of GNOME, XFCE, etc. to switch from Gtk2 to Gtk3 simultaneously isn't really realistic... and if more libraries did this, switching to a newer API wouldn't have to happen for all of Debian at once. (I've found myself wishing libjpeg6b and libjpeg8 headers were parallel-installable, which would let me remove a nasty hack from ioquake3.) S -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110408202310.ga3...@reptile.pseudorandom.co.uk
Re: Patch for MultiarchCross
On Fri, Apr 08, 2011 at 09:51:03PM +0200, Bill Allombert wrote: I already made this comment, but I strongly think it should be normative. Specifically we should mandate that: 1) /usr/include/triplet be added to the default hearder search path of triplet-gcc. It seems strange to me that we would mandate something in policy that affects approximately one package (the compiler). However, I think this is unquestionably the correct thing for the compiler to do, so if there's general agreement that it belongs in policy I'll happily second. 2) Packages that would install headers in /usr/include/path install them in /usr/include/triplet/path This is too strong a requirement. The majority of headers can still be installed to /usr/include/path because they're invariant between architectures. It's only when a header needs to contain different contents between different architectures that /usr/include/triplet must be used. Where possible, I think packages should leave their headers directly under /usr/include, because: - it reduces duplication of data on disk (but headers are small compared to libraries, so this isn't a huge deal) - while it's bad form to depend on specific filesystem paths for headers rather than using the compiler include path, there are plenty of packages in the archive whose build systems are bad form. We're in uncharted waters here, and I don't think we should make ourselves more incompatible with existing software than is strictly necessary. Requiring the user to pass -I to the compiler should be discouraged. Note that this discouragement is in conflict with the upstream behavior of a number of libraries, including much of the GNOME stack which uses pkg-config as an interface to declare additional -I arguments. So I'm not convinced putting this in policy adds much value. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Patch for MultiarchCross
On Fri, Apr 08, 2011 at 10:17:20PM +0200, Goswin von Brederlow wrote: What could be allowed is using the new include paths with a Depends on the multiarch package even if the package itself is not multiarch. No. multiarch-support declares runtime support for ld.so. It has nothing to do with include paths (or -dev packages in general) and should not be abused like this. Will there be a multiarch-dev-support then or will -dev packages have to Depends on the right versions of a number of build tools? Why do you need either? What real problem are you trying to solve? multiarch-support is needed to ensure users's systems don't render themselves completely unusable in the middle of an upgrade. multiarch-dev-support would be a lot of work to solve something that is merely an inconvenience - a compile-time error that requires the user to upgrade to the current gcc on i386 to fix. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Patch for MultiarchCross
On Fri, Apr 08, 2011 at 02:01:33PM -0700, Steve Langasek wrote: On Fri, Apr 08, 2011 at 09:51:03PM +0200, Bill Allombert wrote: I already made this comment, but I strongly think it should be normative. Specifically we should mandate that: 1) /usr/include/triplet be added to the default hearder search path of triplet-gcc. It seems strange to me that we would mandate something in policy that affects approximately one package (the compiler). However, I think this is unquestionably the correct thing for the compiler to do, so if there's general agreement that it belongs in policy I'll happily second. It does not only affect the compiler. It also affects all packages that will provide files in /usr/include/triplet, because this will cause the files to be in the default search path. Packagers need to know that /usr/include/triplet is the 'correct' path to use for that purpose without looking up gcc specfiles. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110408220017.GS3230@yellowpig
