The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guidelines docs on ftp.debian.org.

On Tue, 5 Mar 1996 Dirk.Eddelbuettel@qed.econ.queensu.ca wrote:

>   Dirk> * consistency as all our package names will look similar; this is
>   Dirk> quite a goal for a distribution 
> 
>   Erick> But more visual than functional. 
> 
> Visual aspects do matter. Recognition is important.

Yes, fair enough ... but whether the revision field is mandatory or 
optional isn't likely to make that much difference to recognition, is 
it?  .deb is what people will be looking for, I would have thought, and 
in a source file (.tar.gz), the difference is marginal, IMHO.

> We should have version numbers, upstram or intrinsic in the case of
> Debian-only packages, followed by a revision field.

IYHO? :-)

>   Dirk>  * easier handling for parsing etc

To reiterate Richard Kettlewell's question:

   WHY DO WE NEED TO PARSE FILENAMES WHEN DPKG CAN MANAGE WITHOUT DOING SO?

(This has been asked at least twice already ...)

>   Dirk> * safer design: I use -revision on debian-only packages because I
>   Dirk> know how easy it it to screw in the package *management*, as opposed
>   Dirk> to the package *content*. Why should I increase the version number if
>   Dirk> the content hasn't changed but only the packaging?
> 
>   Erick> You shouldn't increase the version number if only the packaging
>   Erick> changed, Specific debian only packages don't have much changes with
>   Erick> the packaging 
> 
> Again, thanks. This is precisely why we need the revision field for.

You're not a politician, are you? :-)  If you'd read to the end of 
Erick's sentence, he pointed out that a maintainer could add the optional 
revision field for just one release if necessary and then remove it when 
the version number increases.

>   Dirk> I think that dpkg for example, even though it looks like a.b.c,
>   Dirk> really numbers as a.b-revision. Whenever Ian overlooks something at
>   Dirk> compile time (as opposed to a new major function, ie the jumps from
>   Dirk> 0.93.x to 1.0.x to 1.1.x), he increases the last number which hence
>   Dirk> is a *de facto revision field*.
> 
>   Erick> I don't look in the kitchen of Ian J that much but I think he is
>   Erick> using the last field as a patch field. That is what it should be
>   Erick> used for.
> 
> Exactly. It already *is* a revision field. So why is it so difficult to call
> a revision field a revision field? 

NO IT IS NOT A REVISION FIELD!!!

Again, that wasn't what Erick said at all, if anything the opposite.  The 
third field in dpkg version numbers is a PATCHLEVEL, rather like the 
third number in kernel versions.  You don't seriously think that Ian J. 
would have to make 16 changes to the packaging, do you? :-)

Look, this is getting heated, and not achieving much.  We've heard why 
some people think that the revision field should be compulsory, or 
rather, why, in their personal opinions, these are a good thing.  We've 
also heard why some other people think that they should be optional for 
Debian-only packages.

What we haven't heard, I think, is some really convincing reasons why 
making this field compulsory is necessary.  So can we stop arguing, and 
start discussing, please? ...

Nikhil.