Re: Vcs-* and Other Fields
Jonathan Yu jonathan.i...@gmail.com writes: For me it just seems odd to add fields to d/control that aren't in policy, though your explanation makes sense to me. Debian policy is, ideally, descriptive instead of proscriptive. In other words, it (ideally) changes only in response to acknowledged best practices that are *already* being followed and supported by a significant portion of the operating system and infrastructure. Far from being odd, it's encouraging that a practice becomes consensual before appearing in policy. I don't really think that each version control system should have its own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc, because it's simply not very future proof in my opinion. What's the alternative? On the other hand we've got situations where there are lots of Version Control systems that use HTTP and WebDAV (like SVN via http://) so it's hard to detect what type of repository something is simply given the URL. Exactly. If there was a ‘VCS-URL’ field, there would still need to be an additional ‘VCS-tool’ field to hold the information you want to deprecate (the name of the tool that will be needed to interact with the VCS data at the specified URL). Then, since they all have different command-lines, there would need to be an enumerated list of those that are supported. You thereby go from one field to two, without any benefit I can see. -- \“I filled my humidifier with wax. Now my room is all shiny.” | `\—Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Vcs-* and Other Fields
Hi! On Tue, 2009-06-23 at 21:02:53 -0700, Russ Allbery wrote: I don't remember if there's a bug filed asking for inclusion of the Vcs-* fields already. If there isn't and you feel like tracking this down, a bug that has a pointer to the specification would be great, or a proposed specification. For Lintian, we had trouble finding documentation for what the contents should be for some cases, particularly Vcs-Mtn. Most of the spec was drafted in [0] and [1], there's probably related discussions in debian-devel and debian-policy from around that time, but I've not looked them up. The fields added to dpkg-dev were the ones specified in [0]. regards, guillem [0] http://bugs.debian.org/391023 [1] http://bugs.debian.org/393462 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
On Tue, Jun 23, 2009 at 19:13:23 -0700, Martin Dorey wrote:
debian-policy appears to define Installed-Size's units as thousands of bytes:
5.6.20 Installed-Size
This field appears in the control files of binary packages, and in the
Packages files. It gives the total amount of disk space required to install
the named package.
The disk space is represented in kilobytes as a simple decimal number.
I suspect this is informal language describing an intention to use kibibytes
- units of 1024 bytes - as implemented by dpkg-gencontrol's use of du -k:
if (!defined($substvars-get('Installed-Size'))) {
defined(my $c = open(DU, -|)) || syserr(_g(fork for du));
if (!$c) {
chdir($packagebuilddir) ||
syserr(_g(chdir for du to \`%s'), $packagebuilddir);
exec(du,-k,-s,.) or syserr(_g(exec du));
The ambiguity, while not particularly serious at the scale of typical package
sizes, has led to dispute, eg https://bugs.launchpad.net/gdebi/+bug/44286.
Given that Installed-Size largely depends on the filesystem where the
package was built anyway, the difference between 1000 and 1024 doesn't
really matter here IMO.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
Ben Pfaff wrote: Russ Allbery r...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au writes: If you're going that far, please perform one of the following: s/rounded/fractions rounded up/ s/rounded/fractions rounded down/ s/rounded/fractions rounded to the nearest whole number/ to disambiguate the calculation. Does du guarantee to do one of those? The specification at http://www.opengroup.org/onlinepubs/009695399/utilities/du.html says: By default, file sizes shall be written in 512-byte units, rounded up to the next 512-byte unit. But this is an other case, and pretty historical. du indicate the disk usage in block. A file of one byte uses one entire block (but on few filesystems), thus to calculating the quota of a user, one needs the block count and not the sum of the file sizes. Anyway I agree that rounded up is safer. But I still not sure that it is correct. I would change: It gives the total amount of disk space required to install the named package. to It gives an indicative amount of disk space required to install the named package. because the field cannot give the real required disk space: - (we really round up the size of every file?) - On linux kernel the block size could be up to 4096 bytes (and it is filesystem dependent, thus unknown on packing time) - we install also directories (the disk space depends heavily on filesystems). thus I would prefer a *indicative amount* and maybe in a foot note the reason because we cannot put the real disk space. As alternative we indicate only the sum of file sizes, removing the disk space required. ciao cate -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Vcs-* and Other Fields
On Jun 24, 2009, at 8:22, Ben Finney wrote: Jonathan Yu jonathan.i...@gmail.com writes: For me it just seems odd to add fields to d/control that aren't in policy, though your explanation makes sense to me. Debian policy is, ideally, descriptive instead of proscriptive. In other words, it (ideally) changes only in response to acknowledged best practices that are *already* being followed and supported by a significant portion of the operating system and infrastructure. Far from being odd, it's encouraging that a practice becomes consensual before appearing in policy. In addition to the excellent points mentioned in this thread, I'd like to mention one more - downstream might not follow debian policy. Downstream in this case is other distros that rely on debian and debian's packaging infrastructure but perhaps add to the control file an icon or other text (as we do in Maemo). It would make lintian less useful to downstream if policy were a minefield of proscriptive lintian warnings. Of course debian cannot base policy on downstream needs, there are lots of downstream distros nowadays, but being descriptive by default makes life easier. Warm regards, Jeremiah -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
On Tue, Jun 23, 2009 at 07:13:23PM -0700, Martin Dorey wrote: Package: debian-policy Version: 3.7.2.2 Severity: minor debian-policy appears to define Installed-Size's units as thousands of bytes: 5.6.20 Installed-Size This field appears in the control files of binary packages, and in the Packages files. It gives the total amount of disk space required to install the named package. The disk space is represented in kilobytes as a simple decimal number. I suspect this is informal language describing an intention to use kibibytes - units of 1024 bytes - as implemented by dpkg-gencontrol's use of du -k: Could we simply not discuss this issue at all ? This would save time and I do not think anybody would change their mind anyway. 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
Re: Vcs-* and Other Fields
On Wed, Jun 24, 2009 at 04:22:48PM +1000, Ben Finney wrote: Jonathan Yu jonathan.i...@gmail.com writes: I don't really think that each version control system should have its own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc, because it's simply not very future proof in my opinion. What's the alternative? This one is easy: Vcs: git:http://git.debian.org/... Vcs: svn:http://svn.debian.org/... (This means that dpkg does not have to be updated for each new VCS). 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
Re: Vcs-* and Other Fields
On Wed, Jun 24, 2009 at 01:44:10PM +0200, Bill Allombert wrote: On Wed, Jun 24, 2009 at 04:22:48PM +1000, Ben Finney wrote: Jonathan Yu jonathan.i...@gmail.com writes: I don't really think that each version control system should have its own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc, because it's simply not very future proof in my opinion. What's the alternative? This one is easy: Vcs: git:http://git.debian.org/... Vcs: svn:http://svn.debian.org/... (This means that dpkg does not have to be updated for each new VCS). This, or some similar scheme, would certainly be more future proof. One additional thing I'd like to raise is the need for additional metadata to make better use of the VCS repository: - upstream branch - debian branch - possibly additional branches e.g. upstream stable/development branches, and also debian stable/unstable/experimental branches One current annoyance with tools such as git-buildpackage is the need to manually specify options such as the upstream and debian branches unless you stick to the defaults, as well as if tools such as pristine-tar are being used. If this information was present in the control file, and I feel this is a natural place for such information, this would make package maintenance and building within a VCS rather less cumbersome, and could also allow for seamless integration with e.g. dpkg-buildpackage rather than requiring a separate tool for each VCS out there, at least for building. Maybe a set of Vcs*: tags would allow such uses? Vcs: git Vcs-Uri: git://git.debian.org/foo/bar Vcs-Debian: debian/unstable Vcs-Upstream: stable Vcs-Upstream-Stable: stable Vcs-Upstream-Unstable: master There may be better ways of representing things, these are just examples of the information which would be useful. Regular expressions to match tags used for upstream and debian releases would also be useful. There are other potential uses for having this additional information: automated rebasing of patches against new releases, and against the upstream development branch for forwarding upstream. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Vcs-* and Other Fields
Roger: I'm happy to see everyone discussing this, and ways to future proof the idea, though I suppose dpkg will need to continue supporting the old Vcs-* style tags in any case, at least for some transitional period, since they have become a bit of an ad-hoc standard. I'd like to see them deprecated in favour of something similar to the arrangements you and Bill Allombert have mentioned. On Wed, Jun 24, 2009 at 8:50 AM, Roger Leighrle...@codelibre.net wrote: On Wed, Jun 24, 2009 at 01:44:10PM +0200, Bill Allombert wrote: On Wed, Jun 24, 2009 at 04:22:48PM +1000, Ben Finney wrote: Jonathan Yu jonathan.i...@gmail.com writes: I don't really think that each version control system should have its own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc, because it's simply not very future proof in my opinion. What's the alternative? This one is easy: Vcs: git:http://git.debian.org/... Vcs: svn:http://svn.debian.org/... (This means that dpkg does not have to be updated for each new VCS). This, or some similar scheme, would certainly be more future proof. One additional thing I'd like to raise is the need for additional metadata to make better use of the VCS repository: - upstream branch - debian branch - possibly additional branches e.g. upstream stable/development branches, and also debian stable/unstable/experimental branches One current annoyance with tools such as git-buildpackage is the need to manually specify options such as the upstream and debian branches unless you stick to the defaults, as well as if tools such as pristine-tar are being used. If this information was present in the control file, and I feel this is a natural place for such information, this would make package maintenance and building within a VCS rather less cumbersome, and could also allow for seamless integration with e.g. dpkg-buildpackage rather than requiring a separate tool for each VCS out there, at least for building. Agreed. Maybe a set of Vcs*: tags would allow such uses? Vcs: git Vcs-Uri: git://git.debian.org/foo/bar Vcs-Debian: debian/unstable Vcs-Upstream: stable Vcs-Upstream-Stable: stable Vcs-Upstream-Unstable: master This idea seems pretty neat. However, I'm not sure how this sort of arrangement might work in the case where there are multiple repositories. I think it's best to allow users to specify the full URI strings (so that branches don't have to be in the same place). This type of field might be useful for holding information about the upstream Vcs, which would most likely have a different URI than the one for the Debian package maintained by somebody else. There may be better ways of representing things, these are just examples of the information which would be useful. Regular expressions to match tags used for upstream and debian releases would also be useful. There are other potential uses for having this additional information: automated rebasing of patches against new releases, and against the upstream development branch for forwarding upstream. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Maybe if the fields you mention all support URIs and continuations, like: Vcs: git:http:// svn:http://... (It would also be nice of the prefix was optional in the case where you are using svn:// or git:// -- ie the built-in protocols) svn://svn.debian.org/... As well the Vcs list should be ordered in the priority the version control systems are used in practice by developers, perhaps if they use git-svn to synchronize the two. On the other hand I'm not sure if the Vcs-* fields really need to track anything outside Debian, since we just grab tarballs from the upstream Homepage anyway, and that's the purpose of debian/watch. Anyway, I think a way to specify multiple version control systems might be nice, though I'm not sure of its necessity in practise. What is important for all of this, is that we have started a dialogue, and I'm quite pleased we have done so. Cheers, Jonathan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Vcs-* and Other Fields
On Wed, Jun 24 2009, Andrew McMillan wrote: Not at all. There is experimentation in advance of acceptance in this case, and I really don't believe that the overhead of sending every wacky proposal through policy before allowing it to be in the control file would not help the development of new features. True. And the experiment came up with a widely accepted behaviour, which seems to be accepted by other tools (the PTS et al). proposed specification. For Lintian, we had trouble finding documentation for what the contents should be for some cases, particularly Vcs-Mtn. From the Developer's Reference, Vcs-Mtn refers to the mtn (Monotone) version control system. I don't really think that each version control system should have its own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc, because it's simply not very future proof in my opinion. On the other hand we've got situations where there are lots of Version Control systems that use HTTP and WebDAV (like SVN via http://) so it's hard to detect what type of repository something is simply given the URL. I tend to agree, though in reality we essentially do have a two-part identifier, and if we define it as such there is no reason why we can't say that the field is 'Vcs-' + vcs-type + ':' + vcs-url, and future proof it by allowing the list of vcs-types to be defined outside of policy. In this case, if y'all are going to change the practice, you should again do so in the dev-ref, and come to policy when the shiny new design has been deployed, and the tools fixed to match. Until then, it is not yet ready for policy standardization. manoj -- The perpetual obstacle to human advancement is custom. -- John Stuart Mill Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Vcs-* and Other Fields
On Tue, Jun 23 2009, Jonathan Yu wrote: For me it just seems odd to add fields to d/control that aren't in policy, though your explanation makes sense to me. Policy should be minimalistic. Is there any compelling reason to pull this into policy? I don't really think that each version control system should have its own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc, because it's simply not very future proof in my opinion. On the other hand we've got situations where there are lots of Version Control systems that use HTTP and WebDAV (like SVN via http://) so it's hard to detect what type of repository something is simply given the URL. There was a lot of discussion I'll file a bug report against debian-policy sometime tomorrow, though I don't think this is something we can resolve without *much* further discussion. Well, policy is not the place to do Design in. We I think given the stuff in the Developer Reference, we have a good head start on what to put in Policy for this field, but I'd like to see what discussion might have happened surrounding the Vcs fields in the first place, and build on that for policy. I think the Developer Reference is the closest we're going to get to a proposed specification. Please go look at the archives. It looks like the intent of having several fields for different Vcs mechanisms is that you can put several systems per package. So if you maintain your package in Svn and Git, you could have Vcs-Svn and Vcs-Git repositories for that. You could. But hten you will have to have the discussion, convince people to agree to the new design, get it into dev-ref, get the tools patched, and _then_ come back with a compelling argument why th enew design belongs in policy. It seems like it's reached the point where it's an ad-hoc standard and I think that makes it a reasonable candidate for inclusion into Debian Policy, though this might mean hammering out a clearer standard. Hopefully it follows the same fate as Homepage. The homepage was not really changed before it went into policy; it was an accepted practice, with a stable policy, by the time it was included. Policy is genrally is not the place to pull in new design. manoj -- Any man who hates dogs and babies can't be all bad. Leo Rosten, on W.C. Fields Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Vcs-* and Other Fields
On Wed, Jun 24 2009, Roger Leigh wrote: This, or some similar scheme, would certainly be more future proof. One additional thing I'd like to raise is the need for additional metadata to make better use of the VCS repository: - upstream branch - debian branch - possibly additional branches e.g. upstream stable/development branches, and also debian stable/unstable/experimental branches One current annoyance with tools such as git-buildpackage is the need to manually specify options such as the upstream and debian branches unless you stick to the defaults, as well as if tools such as pristine-tar are being used. If this information was present in the control file, and I feel this is a natural place for such information, this would make package maintenance and building within a VCS rather less cumbersome, and could also allow for seamless integration with e.g. dpkg-buildpackage rather than requiring a separate tool for each VCS out there, at least for building. Maybe a set of Vcs*: tags would allow such uses? Vcs: git Vcs-Uri: git://git.debian.org/foo/bar Vcs-Debian: debian/unstable Vcs-Upstream: stable Vcs-Upstream-Stable: stable Vcs-Upstream-Unstable: master This will delay inclusion into policy; since you will have to get people to agree to this change, and wait until the new convention is adopted (we have an installed mass of packages using the current scheme. Of course, if that is done, and the new convention wins over the old one, there might be reason to have policy about it -- which one of the two conventions to use would be specified by policy one the transition is mostly complete. But it seems to be that this might be getting close to over engineering the issue. manoj -- Be cheerful while you are alive. Phathotep, 24th Century B.C. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Vcs-* and Other Fields
Manoj Srivastava sriva...@debian.org writes: On Tue, Jun 23 2009, Jonathan Yu wrote: For me it just seems odd to add fields to d/control that aren't in policy, though your explanation makes sense to me. Policy should be minimalistic. Is there any compelling reason to pull this into policy? Well, from my perspective, the main reason why I'd like to have it in Policy is that people have started making errors in the fields (putting the Vcs-Browser URL in Vcs-Svn, etc.), and it would be nice to have a clear specification against which one can write Lintian checks. That specification could, of course, be in the devref, but it's nice to put established specifications in Policy precisely because they then don't change much. Also, as mentioned, we had real trouble finding documentation for what was supposed to go into the Vcs-Mtn field, since Monotone doesn't use URLs. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
interested in you
You are invited to interested in you. By your host Joy Dabor: Date: Wednesday June 24, 2009 Time: 5:00 pm - 6:00 pm (GMT +00:00) Street:Hi dear, how are you today isaw you email today and hope that every things is ok with you as it is my great pleassure to contact you in having communication with you, please i wish you will have the desire with me so that we can get to know each other better and see what happened in future. i will be very happy if you can write me through my email for easiest communication and to know all about each other, and also give you my pictures and details about me, here is my email (joycedab...@yahoo.com) i will be waiting to hear from you as i wish you all the best for your day. your new friend. joy Guests: * martin.ferr...@gmail.com * mar...@v.loewis.de * m...@wuertele.net * sjog...@debian.org * mar...@walnut.methody.org * m...@bork.org * zw...@zwets.com * mpr...@lugroma.org * m...@debian.org * mtizn...@linux.org.ar * m...@thing.demon.co.uk * mcg...@ruslug.rutgers.edu * lbre...@insalien.org * l...@dooz.org * g...@lsc.hu * k...@debian.org * kha...@gonehiking.org * pgd-karolin...@algonet.se * k...@debian.org * ptitlo...@andesi.org * jul...@mehnle.net * juer...@strobel.info * js...@debian.org * j...@prairienet.org * j...@drystone.co.uk * j...@dhh.gt.org * j.jord...@ucl.ac.uk * j...@debian.org * j...@debian.org * jes...@zedlitz.de * jwarn...@beeznest.net * j...@debian.org * licq...@debian.org * he...@debian.org * a...@bofh.net.pl * jmalo...@unpluggable.com * j...@vanzandt.mv.com * ja...@gnifty.net * rkru...@debian.org * ita...@oktiva.com.br * i...@chiark.greenend.org.uk * ie...@debian.org * j2se-pack...@z42.de * ben...@debian.org * reds...@abc.se * hans.ofverb...@home.se * g...@alumni.brown.edu * ad...@debian.org * alger...@debian.org * gekhajof...@netinfo.fr * ge...@f-451.net * gryckeb...@virtual-net.fr * che...@the-geek.org * f...@centrotemporeale.it * fr...@lichtenheld.de * fjor...@debian.org * mat...@debian.org * fpane...@aliceposta.it * ferna...@softwarelivre.org * fai...@cube.gr * e...@jdba.org * gagnon.etienn...@uqam.ca * er...@double-helix.org * ander...@debian.org * d...@zorglub.s.bawue.de * si...@nuit.ca * p...@mind.be * dholl...@free.fr * den...@debian.org * dbug...@debian.org * debian-devel-portugu...@lists.debian.org * debian-a...@lists.wedontsleep.org * debian-xml-sgml-p...@lists.alioth.debian.org * vba-ma...@triplehelix.org * pack...@qa.debian.org * packa...@qa.debian.org * debian-policy@lists.debian.org * pkg-java-maintain...@lists.alioth.debian.org * pkg-nethack-de...@lists.alioth.debian.org * pkg-mono-gr...@alioth.debian.org * pkg-lyx-de...@lists.alioth.debian.org * debian-ker...@lists.debian.org * da...@davidpashley.com * dav...@sponge.xevion.net * da...@eelf.ddts.net * da...@debiancolombia.org * d...@debian.org * li...@youmustbejoking.demon.co.uk * ciancaleo...@libero.it * d...@con-fuse.org * de...@walki invitation_add_to_your_yahoo_calendar: http://calendar.yahoo.com/?v=60ST=20090624T17%2BTITLE=interested+in+youDUR=0100VIEW=din_st=Hi+dear,+how+are+you+today+isaw+you+email+today+and+hope+that+every+things+is+ok+with+you+as+it+is+my+great+pleassure+to+contact+you+in+having+communication+with+you,+please+i+wish+you+will+have+the+desire+with+me+so+that+we+can+get+to+know+each+other+better+and+see+what+happened+in+future.+i+will+be+very+happy+if+you+can+write+me+through+my+email+for+easiest+communication+and+to+know+all+about+each+other,+and+also+give+you+my+pictures+and+details+about+me,+here+is+my+email+(joycedab...@yahoo.com)+i+will+be+waiting+to+hear+from+you+as+i+wish+you+all+the+best+for+your+day.+your+new+friend.+joyTYPE=10 Copyright © 2009 All Rights Reserved www.yahoo.com Privacy Policy: http://privacy.yahoo.com/privacy/us Terms of Service: http://docs.yahoo.com/info/terms/
Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
On Tue, Jun 23, 2009 at 07:49:40PM -0700, Russ Allbery wrote: Martin Dorey mdo...@bluearc.com writes: debian-policy appears to define Installed-Size's units as thousands of bytes: 5.6.20 Installed-Size This field appears in the control files of binary packages, and in the Packages files. It gives the total amount of disk space required to install the named package. The disk space is represented in kilobytes as a simple decimal number. I suspect this is informal language describing an intention to use kibibytes - units of 1024 bytes - as implemented by dpkg-gencontrol's use of du -k: Agreed. At the time Policy was originally written, kilobyte nearly universally meant kibibyte in the industry. I'll change this to: The disk space is given as the integer value of the installed size in bytes divided by 1024 and rounded (in other words, the size in kibibytes). for the next release. (I believe this is an informative change that doesn't require seconds.) I would prefer if the word kibibyte was not used in policy, so I would strike '(in other words, the size in kibibytes)'. 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
Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: I would prefer if the word kibibyte was not used in policy, so I would strike '(in other words, the size in kibibytes)'. I don't much like the word either, but at this point it's an IEEE and ISO standard (IEEE 1541-2002). My feeling is that standards are more important than aesthetics and we should generally follow established standards in areas like this unless there's some compelling reason not to. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
Giacomo A. Catenazzi wrote: I would change: It gives the total amount of disk space required to install the named package. to It gives an indicative amount of disk space required to install the named package. because the field cannot give the real required disk space: - (we really round up the size of every file?) - On linux kernel the block size could be up to 4096 bytes (and it is filesystem dependent, thus unknown on packing time) - we install also directories (the disk space depends heavily on filesystems). Add to that: - Packages may install/create in postinst that isn't taken into account in Installed-Size. So your change makes sense. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Vcs-* and Other Fields
On Wed, Jun 24, 2009 at 01:50:20PM +0100, Roger Leigh wrote: One additional thing I'd like to raise is the need for additional metadata to make better use of the VCS repository: - upstream branch - debian branch - possibly additional branches e.g. upstream stable/development branches, and also debian stable/unstable/experimental branches I don't think this stuff is relevant to keep in debian/control; the Debian branch is the only one that maintainers should have to care about. At *most*, we should only be encoding the upstream branch corresponding to the current package, but I'm not keen on this either. Maybe a set of Vcs*: tags would allow such uses? Vcs: git Vcs-Uri: git://git.debian.org/foo/bar Vcs-Debian: debian/unstable Vcs-Upstream: stable Vcs-Upstream-Stable: stable Vcs-Upstream-Unstable: master This is not an abstraction that maps appropriately on all VCSes (or even on all uses of a given VCS). For a number of use cases, you have one URI per branch; I think you want to sort out a URI format for git that can encode the branch information as well. -- 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 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
Hi! On Wed, 2009-06-24 at 22:25:15 +0200, Emilio Pozuelo Monfort wrote: Giacomo A. Catenazzi wrote: I would change: It gives the total amount of disk space required to install the named package. to It gives an indicative amount of disk space required to install the named package. because the field cannot give the real required disk space: - (we really round up the size of every file?) - On linux kernel the block size could be up to 4096 bytes (and it is filesystem dependent, thus unknown on packing time) - we install also directories (the disk space depends heavily on filesystems). Add to that: - Packages may install/create in postinst that isn't taken into account in Installed-Size. That's what the Extra-Size substvar is for (see deb-substvars(5)), but... So your change makes sense. ... yes, even with that it's still an approximation. regards, guillem -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Vcs-* and Other Fields
On Wed, Jun 24, 2009 at 04:38:27PM -0400, Steve Langasek wrote: On Wed, Jun 24, 2009 at 01:50:20PM +0100, Roger Leigh wrote: One additional thing I'd like to raise is the need for additional metadata to make better use of the VCS repository: - upstream branch - debian branch - possibly additional branches e.g. upstream stable/development branches, and also debian stable/unstable/experimental branches I don't think this stuff is relevant to keep in debian/control; the Debian branch is the only one that maintainers should have to care about. At *most*, we should only be encoding the upstream branch corresponding to the current package, but I'm not keen on this either. If one is using a tool such as git-buildpackage, the debian and upstream branches are the *minimum* required information however. IMO these need to be spelled out explicitly in order to build a correct package. Obviously the maintainer knows what these are, and more often an not they are master and upstream in any case, which matches the defaults. But this falls apart as soon as you stop using the defaults, which is why I would like to see these two bits of information in debian/control. One branch could potentially be encoded in the Git URI, but you really need both. The other information is less useful, but I would very much appreciate the information to allow tools to be written to use it (but this is a less immediate concern). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
Russ Allbery r...@debian.org writes: Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: I would prefer if the word kibibyte was not used in policy, so I would strike '(in other words, the size in kibibytes)'. I don't much like the word either, but at this point it's an IEEE and ISO standard (IEEE 1541-2002). My feeling is that standards are more important than aesthetics and we should generally follow established standards in areas like this unless there's some compelling reason not to. +1. The unit being discussed (number of bytes divided by 1024) has an internationally-accepted standard term, and even if we find the term ugly we should acknowledge that term in our use of that unit to clarify the intent. -- \ “If you can do no good, at least do no harm.” —_Slapstick_, | `\ Kurt Vonnegut | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
On Thu, 2009-06-25 at 12:22 +1000, Ben Finney wrote: Russ Allbery r...@debian.org writes: Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: I would prefer if the word kibibyte was not used in policy, so I would strike '(in other words, the size in kibibytes)'. I don't much like the word either, but at this point it's an IEEE and ISO standard (IEEE 1541-2002). My feeling is that standards are more important than aesthetics and we should generally follow established standards in areas like this unless there's some compelling reason not to. +1. The unit being discussed (number of bytes divided by 1024) has an internationally-accepted standard term, and even if we find the term ugly we should acknowledge that term in our use of that unit to clarify the intent. /AOL While a 'kilobyte' was a close enough approximation of a 'kibibyte', the percentage difference gets much more significant as we increase disk size. 1000 1024 102.40% 100 1048576 104.86% 10 1073741824 107.37% 1 1099511627776 109.95% 1000 1125899906842620 112.59% We should just use the right term, and we should collectively get over any dislike of it. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Let us not seek to satisfy our thirst for freedom by drinking from the cup of bitterness and hatred. -- Martin luther King Jr. signature.asc Description: This is a digitally signed message part
