'J.H.M.Dassen wrote:'
>
>Bruce wrote:
>> Also, we should think about source packaging again. We are welcome to take
>> anything we want from RPM source packaging, if that would help.
>
>RPM has the advantage that it include _pristine_ source (identical
>(cmp or md5sum-wise) to the upstream sources,
On Wed, 19 Jun 1996, Chris Fearnley wrote:
> But I like that the Debian source packages
> can be untarred by anyone without dpkg and/or rpm installed.
I also think that's important. The source packages should be very
simple, and the source unpacker/packer should be written in a scripting
languag
> 'J.H.M.Dassen wrote:'
> >Bruce wrote:
> >> Also, we should think about source packaging again. We are welcome to take
> >> anything we want from RPM source packaging, if that would help.
> >
> >RPM has the advantage that it include _pristine_ source (identical
> >(cmp or md5sum-wise) to the upstr
> I also think that's important. The source packages should be very
> simple, and the source unpacker/packer should be written in a scripting
> language.
tar xzf source-version.tar.gz
mv source.version source.version.orig
tar xzf source-version.tar.gz
cd source.version
zcat ../diff-version-revisio
I think we should look at adapting the src.rpm format to debian's needs, but
I haven't investigated it enough to know how practical an idea that is.
Bruce
Erick Branderhorst <[EMAIL PROTECTED]> writes:
Does anyone else have any opinions about this issue? We (Erick and I)
have been babbling on about this, and I didn't know if everyone else's
silence was a lack of interest or a general agreement. i.e. Is this
something that people think is worth wor
Rob Browning writes:
> be used when building packages, no problem. In fact I'd probably just
> write a wrapper (perl) script that looks at the args, handles the mode
> and owner flags itself (as mentioned earlier), and then calls the
> normal install for the rest of the job (stripping, copyin
[EMAIL PROTECTED] writes:
> Makes a lot of sense to me, can you hack install to do such a thing?
You mean actually modify the source for /usr/bin/install itself so we
have a new install that's Debian specific, I'd be really nervous about
that. But if you mean either writing a substitute program
>
> [EMAIL PROTECTED] (Erick Branderhorst) writes:
>
> > I don't think it can be done this way, because a lot of makefiles are
> > organized in a way that they require the installer to be root at the
> > moment of installation, or am I misinformed?
> > Perhaps fooling install might be an option?
> Since we're going to be
> moving every file in "unstable" anyway, that sounds like a good time to
> switch from "unstable" to a symbolic-linked directory (tentatively called
> "rex").
I recommend putting "rex" under a subdirectory called "releases" or something,
just to reduce clutter and confus
[EMAIL PROTECTED] (Erick Branderhorst) writes:
> I don't think it can be done this way, because a lot of makefiles are
> organized in a way that they require the installer to be root at the
> moment of installation, or am I misinformed?
> Perhaps fooling install might be an option?
What do you m
> The only disadvantage is that for a couple of weeks, the unstable
> directory will not be the real unstable directory. The real one will
> be rex, also reachable through an slink development.
As "unstable" gets unpopulated of real files, it should be repopulated
with symlinks to "rex". So if pe
12 matches
Mail list logo
