Joseph Carter wrote:
> Maybe I'm missing something here (it wouldn't be the first time), but I
> believe wichert said the changes in the non-us archive (ie, that non-us
> is now a section of main, whether the archive happens to be on pandora or
> on master is pretty much irrellivant..) If that is
On Sun, May 16, 1999 at 05:04:53PM -0700, Joey Hess wrote:
> > Maybe I'm missing something here (it wouldn't be the first time), but I
> > believe wichert said the changes in the non-us archive (ie, that non-us
> > is now a section of main, whether the archive happens to be on pandora or
> > on mas
Johnie> This seems to go against current practice -- AFAIK its only been
Johnie> done once ("xbase"), with Overfiend kicking and screaming the whole
Johnie> way.
That's why I asked, I don't like it that much either.
Johnie> Better to put ogonkify in the ogonkify package, and have a2ps
Hi,
>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> It still depends on if we consider non-us/main as a part of main or not.
I would. If it is not, I find the directory name non-us/main
deliberately misleading, and would demand that it be changed
immediately.
manoj
--
Processing commands for [EMAIL PROTECTED]:
> retitle 37342 [AMENDMENT] move to logrotate
Bug#37342: debian-policy: [PROPOSED] move to logrotate
Changed bug title.
>
End of message, stopping processing here.
Please contact me if you need assistance.
Ian Jackson
(administrator, Debian bugs databa
I think DEBIAN/md5sums file should be required for all packages.
md5sums is very useful for security reasons (trojans, fs crash,
unexpected file modification) but a lot of important packages
(sysvinit, dpkg, debianutils, bash, adduser, etc.) don't have
this integrity verification.
I propose any D
On Mon, May 17, 1999 at 04:42:42PM +0200, Piotr Roszatycki wrote:
> I think DEBIAN/md5sums file should be required for all packages.
I think you mean for all packages and all files which they cnotain? Or only
the binaries and libraries?
> md5sums is very useful for security reasons (trojans, fs
> I doubt the usefullness (dpkg is no backup system). But I will not object.
> Indeed, I see some usefulness, but I want to know more about the drawbacks:
> How do you want to verify the sums (using cruft, maybe?). How long will it
> need to check the whole fs, how much disk space will the md5sums
On Mon, 17 May 1999, Piotr Roszatycki wrote:
> For now this system seems to be useless because some Debian packages have
> md5sums file, some others doesn't.
>
> IMHO we should use this system for all packager or completly forget about it.
I agree entirely with this. Personally I think our tim
Marcus Brinkmann wrote:
> > I doubt the usefullness (dpkg is no backup system). But I
> > will not object. Indeed, I see some usefulness, but I want
> > to know more about the drawbacks: How do you want to verify
> > the sums (using cruft, maybe?). How long will it need to
> > check the whole fs
Hi,
Oh no, not again.
>>"Piotr" == Piotr Roszatycki <[EMAIL PROTECTED]> writes:
Piotr> I think DEBIAN/md5sums file should be required for all packages.
Piotr> md5sums is very useful for security reasons
Not really. Any security threat can modify your md5sum file,
which defeat
Hi,
>>"Peter" == Peter S Galbraith <[EMAIL PROTECTED]> writes:
>> After some file system crash or any other seasons I'd like to check
>> which files are corrupted, i.e. by 'debsums' tool.
Peter> This reason alone is enough. I second the motion.
Why reinvent the wheel and further bloa
I "second" the objection. I think, that while the md5sum may not do harm
(although if you're relying on it for security reasons you may be
believing files that have been changed) -- I think we need to put more
thought into this (as suggested: tripwire, juliet filesystem, etc) for
many other reasons
On Mon, May 17, 1999 at 03:27:15PM -0500, Manoj Srivastava wrote:
> Peter> This reason alone is enough. I second the motion.
>
> Why reinvent the wheel and further bloat the packjaging
> system? Tripwire does this just fine.
I second your motion in general (this does not belong into dp
14 matches
Mail list logo
