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: dchanges, architecture component, parseable filenames



Bruce Perens writes ("Re: dchanges, architecture component, parseable filenames"):
> Ian Jackson:
...
> > 2. Is signing release announcements mandatory ?
> 
> It can not be mandatory for people who can not make legal use of PGP.
> These people may have degraded service as far as archive submission
> is concerned, as they may need more manual intervention by the
> archive maintainer.

This discussion (the crypto-FUD) need not be here on the list, but I'd
appreciate it if anyone who thinks they can't make legal use of PGP
for signing things would mail me to tell me why.  I don't know of any
countries where we're likely to have developers where this is the
case.  NB: please don't comment on this paragraph on the list - mail
me privately so that I can explain it to you first, and if you still
think I'm wrong you can then post a correctly :-).

...
> Posting an announcement is important but not mandatory. Eventually,
> the announcement will be made from the .changes file (with suitable
> reformatting) automaticaly or when the archive maintainer installs
> your file.

I'm becoming more inclined to suggest that the announcement should be
created at the maintainer's end.  That way the maintainer can
cryptographically sign both the changes file and the release
announcement.  The system on the archive would still check that the
announcement corresponded to the changes file before sending it.

> > 5. Do package .deb files need to contain Section and Priority fields ?
> 
> I think dselect works a lot better with a "Section" field, and if you
> want a Priority field you should say so. Whether this is mandatory
> is up to you, Ian.

I'm happy to leave it optional if the archive management system
doesn't need it for anything.  This information is usually found by
dselect from the Packages file; the stuff in the .deb file is used
only if you install a .deb file without getting the Packages file and
using `Update'.  In fact, I'd quite like to encourage people to use
`Update' ...

[ Parseable filenames ]
...
> > The most aesthetic option for (e) I can think of at the moment is
> > replacing hyphens with underscores in the package name.
> 
> That sounds fair to me. Unless I hear a chorus of "that's repulsive"
> and "this way is better", there may not be a need for a vote. The
> proposal is to make the package file name be:
> 
> PACKAGE_NAME: [^-]*	# Anything but hyphen. Hyphens are replaced
> 			# by underbars automaticaly.

I can live with this, and noone has complained.  Wow !  OK, I'll
change dpkg-name (Erick Branderhorst's script to rename .deb files to
their canonical names).

Guy Maor writes ("Re: dchanges, architecture component, parseable filenames"):
> On Tue, 23 Apr 1996, Ian Jackson wrote:
> > 1. Use of dchanges: fine if this is made mandatory, but we need to
> > have a specification of the output format that is separate from the
> > implementation.
> 
> Is dchanges(5) not that?

Yes, it is.  Sorry that I didn't look for it !  I'm so used to having
things be undocumented around here (and it's mainly my doing or lack
of doing ...)

Bruce Perens writes ("Re: dchanges, architecture component, parseable filenames"):
> I wrote:
> > VERSION_NAME: [^-]*     # With emphasis to use something that
> >                         # can be sorted reliably. This may mean
> >                         # converting "Beta1" to a ".1" on the end
> >                         # of a number, etc.
> 
> Sorry, this was not what Ian intended. I think his intent was for
> the version name to be any character string. The file name can
> still be parsed unambiguously if the package name doesn't contain
> dashes.

Yes, that's right.

Ian.