[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What warrants a non-maintainer release number?



On  6 Jan, Kai Henningsen wrote:
> fpolacco@icenet.fi (Fabrizio Polacco)  wrote:
> 
>> On  6 Jan, Remco Blaakmeer wrote:
>> > So, the people on debs.fuller should make sure
>> > that the version numbers they use will not be taken by 'official' .deb
>> > packages.
>>
>> This sounds nonsense.
> 
> It's the only option we have.

The only option we have is to find a way to say if a package is
official or not (and it cannot be its presence in the ftp site).


> Simple example: someone  
> grabs a source package and rebuilds it without any changes. He will now  
> have a different .deb (and it _will_ be different - different time stamps,  
> maybe he used a different gcc, different debmake version ...) with the  
> exact same version number as the original.
> 

Yes, and therefore, as Christian has just recalled, we need to add an
"origin" field somewhere _inside_ the binary package.
It cannot be included by the maintainer, because not all the packages
that a maintainer build will become "official", and also a maintainer
can step out from the project (and still use his own pgp key).

My suggestion was that dinstall will unpack the .deb , insert some
signature in it (for example a md5sum list of the files in the
control.tar.gz, pgp-signed with an official key), and repack it just
before installation in the ftp hierarchy.
(If the control.tar.gz contains the md5sums of the files installed by
the package, then installing also this signed list into dpkg/info would
add a way to check if a single file is the one distributed by us.)

pgp-signing the Packages file could be another way to achieve this (the
origin field), but will be too easily broken on rearranged distributions
(e.g: your own mirror, or a custom CD), and the signature will be lost
when updating the available list (that is to say: _before_
installation).


> Just close bug reports referring to non-project .debs with "not our  
> package, not our problem".

The problem is "knowing" when a bug refers to a non-project package.
When the user is sending us such bugs, probably he didn't notice or
remember that the package wasn't build by us.
Without a trusted origin field you will be prosecuted by the suspicion
if the package is original or not.
If the signature (that certifies that a package is debian-original), is
installed in the dpkg database then we could have the "bug" command (or
else) add automatically this information to the report.


Fabrizio
-- 
| fpolacco@icenet.fi    fpolacco@debian.org    fpolacco@pluto.linux.it
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> Just because Red Hat do it doesn't mean it's a good idea. [Ian J.]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: