Re: Bug#540215: Introduce dh_checksums
Wouter Verhelst wrote:
> On Fri, Mar 19, 2010 at 09:14:13AM +0100, Frank Lin PIAT wrote:
>> On Thu, 2010-03-18 at 12:39 +0100, Harald Braumann wrote:
>> > On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote:
>> > > Russ Allbery <rra@debian.org> writes:
>> > > > Simon McVittie <smcv@debian.org> writes:
>> > >
>> > > >> Most packages (in terms of proportion of the archive, in
>> particular for
>> > > >> architectures other than i386 and amd64) are built by a buildd,
>> so each
>> > > >> buildd would have to have a signing key that could sign the
>> checksums
>> > > >> file during build.
>> >
>> > Self-contained packages, where the signature is included and installed
>> > along with the checksum file, would have a lot of
>> > advantages. You wouldn't need access to a lot of infrastructure just
>> > to verify a signature. It would be very simple. It could be used for
>> > packages, that are not part of Debian. For instance, I could produce a
>> > package and send it to a friend and he could later use my key for
>> > verification.
>>
>> Oh please no. Don't advocate sending individual .deb files, ever.
>
> That already happens, will always happen, and it cannot be avoided.
I wish we could avoid it for end-users & "consumer products".
> There are perfectly valid use cases for using "individual .deb files".
> To give but one example that comes directly from my day job: I build an
> image for an embedded system that boots off a read-only /.
You build, you deploy, you trust your self. Is is the best example out
there ?
I must admit it is still a valid example.
> Since we
> can't modify our filesystem after booting, the way an update is done is
> through "regenerate the image and boot off a USB stick", rather than
> "apt-get update". Since the latter doesn't work anyway, setting up a
> full repository with Packages file and whatnot is vast overkill, so the
> software that was written specifically for this system is packaged as a
> .deb file that is not in a repository, anywhere.
>
>> This practice should be strongly discouraged. One brilliant part of
>> Debian packaging *is* the APT infrastructure, some key features:
>
> In the above example:
>
>> 1. Security updates
>
> Does not apply (when the devices are connected to a network, that means
> they're either undergoing maintenance or someone is trying to break into
> the system)
In your scenario, the system adminitrator fetch the source from the
distributor (That can/should be done through an APT mirror), then deploy
the managed systems.
>> 2. Bug fixes
>
> "If it ain't broken, don't fix it" applies even more to this kind of
> embedded systems than it does to servers.
In my organisation, we do deploy service pack and point release,
Even though the perceived state would suggest "If it ain't broken, don't
fix it"
>> 4. Dependency resolution
>
> "apt-get -f install"
>
>> 5. Smoother dist-upgrades because:
>> 5a. The APT repository provides newer version, with updated
>> dependencies (libraries transitions...)
>
> the custom software does not include libraries
Don't they include libraries?
Don't they depend on Debian libraries?
Wouldn't that prevent smooth upgrades?
And more important, who the users are going to blame? The broken package
or Debian (my conviction is that people will blame the OS vendor)
>> 6. Single GPG key to manage (revocation ; update...)
>
> I don't understand what you mean by that.
If each package is signed by a DD, a system admin have to manage multiple
public keys.
>> 7. Single GPG key to trust (per repository)
>
> Well, signatures on .deb files would also have a "single" GPG key to
> manage, per source. There's no difference here, really.
>
> It's important to remember that whatever environment you're using Debian
> in, is not necessarily the *only* environment Debian is used in.
This is a very valid point.
> Since a method that will work for individual .debs will also
> work for archive-wide installations, there really is no problem
> in doing it in such a way that it will work for both ways.
Yes, I am really concerned with the "consumer products" users.
(and the usual "do the easiet and faster way, long term
consequences doesn't matter", see teh banner on [1])
BTW in 12 days, I will send a "AUTORUN.DEB" proposal:
Any package named AUTORUN.DEB present on a removable media should
be automatically installed when that media in inserted. ;-)
Regards,
Franklin
[1] http://packages.debian.org/lenny/i386/dash/download
Reply to: