Re: native pkg versioning (was Re: Question about native packages)
On Mon, Feb 05, 2001 at 12:54:04PM +1100, Brian May wrote: [re: non-debian specific programs whose author/maintainer also maintains the debian package.] Some people don't want to do worry about this, so these people can use native format, and not have to worry about the extra diff file. They can indeed, but I think the point is that we want to try to discourage this, especially for big packages, due to the extra load on the mirrors. It's not against the rules, it's merely rude, as it were. On the other hand, it's a sign of laziness, and I think laziness is a virtue, so I have mixed feelings about the whole thing. In general, laziness can be a great boon if applied intelligently (I'm tired of adding up columns and rows of numbers all the time, I think I'll invent the spreadsheet so the computer can do this for me.) I think the best thing is to continue to allow this, and only complain in cases where the package is so large, and uploaded so frequently, that it really is a problem for our mirrors. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: native pkg versioning (was Re: Question about native packages)
Chris == Chris Waters [EMAIL PROTECTED] writes: Chris On the other hand, it's a sign of laziness, and I think Chris laziness is a virtue, so I have mixed feelings about the Chris whole thing. In general, laziness can be a great boon if Chris applied intelligently (I'm tired of adding up columns and Chris rows of numbers all the time, I think I'll invent the Chris spreadsheet so the computer can do this for me.) I think Chris the best thing is to continue to allow this, and only Chris complain in cases where the package is so large, and Chris uploaded so frequently, that it really is a problem for our Chris mirrors. I disagree. Why should dpkg, for instance, which is specific to Debian come with a diff format. So maybe native format might be used when it shouldn't, but that doesn't mean that some applications exist. IMHO all packages that are specific to Debian (eg. use on other platforms is not supported) fall into this category. -- Brian May [EMAIL PROTECTED]
Re: native pkg versioning (was Re: Question about native packages)
* Brian May [EMAIL PROTECTED] [010205 02:39]: I disagree. Why should dpkg, for instance, which is specific to Debian come with a diff format. Ah, but dpkg isn't specific to Debian. It is licensed in such a fashion that allows its use in other projects. (Of course, anyone likely to use dpkg elsewhere is liable to take our version number as the 'upstream' version, grab the source, and repackage the thing on their own.) -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: native pkg versioning (was Re: Question about native packages)
On Sun, 04 Feb 2001, Manoj Srivastava wrote:
Henrique == Henrique M Holschuh [EMAIL PROTECTED] writes:
I don't see where the source or binary package enter the
picture here. What am I missing?
Currently, policy says NOTHING about native packages and debian revision
fields. That means a native package (both source==.tar.gz+.dsc and the
binaries==.deb) can, *if they want*, have a debian version field ('-1') as
well as the upstream version field.
I want to forbid native SOURCE packages (i.e.: the .tar.gz+.dsc) to have
such version fields, and to say nothing at all about native .debs (because I
could care less about native .debs with a debian revision field -- the
problem I want to fix happens only in source packages).
Normally, that means the native .deb will NOT have a debian version field.
However, if a porter or autobuilder wants to tack one to a .deb and make a
binary-only NMU, I was not going to forbid it in policy.
Are you saying I have
bar_1.1.tar.gz
bar_1.1.dsc
bar1_1-13_i386.deb
?
Right now you COULD have the above, yes. I was not going to forbid it in my
policy proposal, because it is not important to the problem I am trying to
solve.
I want to have
foo_1.1.dsc
foo_1.1.tar.gz
foo_1.1_i386.deb
bar_1.1.orig.tar.gz
bar_1.1-13.dsc
bar_1.1-13.diff.gz
bar_1.1-13_i386.deb
What I am going to propose is not going to forbid any of the above, either.
But the proposal *will* forbid:
foobar_1.1-2.tar.gz
foobar_1.1-2.dsc
--
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
pgphuqmgXoHEl.pgp
Description: PGP signature
native pkg versioning (was Re: Question about native packages)
(all CC:s removed) On Sun, 04 Feb 2001, Manoj Srivastava wrote: - if yes, do as you wish. But be warned that I'll be proposing in policy Henriquethat *SOURCE* (not binary) native packages be forbidden Henriquedebian revision fields (there's a good reason for that, Henriquesee thread in -policy). And I'll be opposing that since I do not see the reason for separating the source vs binary package as far as versioning is concerned. Erk. Let me see if I understood your point... You would not oppose forbidding debian revision fields for native packages (binary and source), but will oppose forbidding debian revision fields for native packages (source) and not for native packages (binary) ? I was actually thinking of a proposal that makes it clear that it is forbidden for native source packages, and says nothing (and implies nothing) at all for native binary packages (since the current policy does not say anything about both anyway). -- 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 pgphiwMxGhSu7.pgp Description: PGP signature
Re: native pkg versioning (was Re: Question about native packages)
Henrique == Henrique M Holschuh [EMAIL PROTECTED] writes: Henrique Erk. Let me see if I understood your point... Henrique You would not oppose forbidding debian revision fields for Henrique native packages (binary and source), but will oppose Henrique forbidding debian revision fields for native packages Henrique (source) and not for native packages (binary) ? Umm. I did not understand this at all. I guess you shall have to explain the distinction between native packages (source) and native packages (binary) to me. Say, I have a native package foo. Now, foo is small, and for the most cases the changes I upload reflect changes in the source; and in the case there is only a packaging change, well, the debian diff is the same order as the whole package, so it does not make any sense to create a separate debian revision. Now I have another package baz, which I am also upstream for. a) I want to release baz to the whole world, not just debian, but I do not want to create a new package whenever a debian package change occurs b) The package is huge, and I do not want to upload the whole source.tar.gz whenever a packaging change occurs; I create a orig,tar,gz, a diff.gz (containing the ./debian dir, for the most part), and a debian revision; just packaging changes do not cause the whole source to be uploaded, or the ``upstream'' version changed. I don't see where the source or binary package enter the picture here. What am I missing? Are you saying I have bar_1.1.tar.gz bar_1.1.dsc bar1_1-13_i386.deb ? I want to have foo_1.1.dsc foo_1.1.tar.gz foo_1.1_i386.deb bar_1.1.orig.tar.gz bar_1.1-13.dsc bar_1.1-13.diff.gz bar_1.1-13_i386.deb Are we in disagreement here? What is it that you are calling a (source) package? As I see it, bar source == bar_1.1.orig.tar.gz + bar_1.1-13.dsc + bar_1.1-13.diff.gz? foo source == foo_1.1.tar.gz + foo_1.1.dsc manoj thoroughly confused now -- Trying to break out of the Tempter's control, one's mind writhes to and fro, like a fish pulled from its watery home onto dry ground. 34 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: native pkg versioning (was Re: Question about native packages)
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj Say, I have a native package foo. Now, foo is small, Manoj and for the most cases the changes I upload reflect changes Manoj in the source; and in the case there is only a packaging Manoj change, well, the debian diff is the same order as the Manoj whole package, so it does not make any sense to create a Manoj separate debian revision. In case you want a diff file, then just treat the whole package as a normal non-native package. No problem. Manoj I want to have foo_1.1.dsc foo_1.1.tar.gz foo_1.1_i386.deb Manoj bar_1.1.orig.tar.gz bar_1.1-13.dsc bar_1.1-13.diff.gz Manoj bar_1.1-13_i386.deb Exactly the same as a non-native package. No one (as far as I am aware) is trying to force you to create a native package just because you happen to be the author as well as the packager. You have to be careful to keep the roles (upstream author vs maintainer) separate (eg. don't get confused and put upstream changes in the Debian diff file or vice-versa). Even if you do get this wrong, it is still easy to fix, just release a new upstream version. Some people don't want to do worry about this, so these people can use native format, and not have to worry about the extra diff file. -- Brian May [EMAIL PROTECTED]
Re: native pkg versioning (was Re: Question about native packages)
Now I have another package baz, which I am also upstream for. a) I want to release baz to the whole world, not just debian, but I do not want to create a new package whenever a debian package change occurs You could just release it to Debian, but not to sunsite. And you upload it to sunsite only when there's something relevant to the rest of the world.
