On Tue, 4 Dec 2001, Jack Coates wrote:
> On Tue, 4 Dec 2001, Charles Steinkuehler wrote:
>
>
> > Yeah, I think it's pretty big, plus I believe most of these packages require
> > openssl and other huge add-ons to run. The basics of public-key
> > cryptography, however, are pretty simple, so I t
On Tue, 4 Dec 2001, Charles Steinkuehler wrote:
> Yeah, I think it's pretty big, plus I believe most of these packages require
> openssl and other huge add-ons to run. The basics of public-key
> cryptography, however, are pretty simple, so I think it'd be possible to
> make a small (a few K, pe
> >Yeah, I think it's pretty big, plus I believe most of these packages
> require
> >openssl and other huge add-ons to run. The basics of public-key
> >cryptography, however, are pretty simple, so I think it'd be possible to
> >make a small (a few K, perhaps) binary that would simply calculate an
Charles Steinkuehler wrote:
> OK, I think we're closer than I previously thought on the issue of format.
> I have always felt the bulk of the package should be in a 'classic' gzipped
> tar file (this probably wasn't clear), but that some sort of extension is
> required to tack on additional meta-
Charles Steinkuehler wrote:
>Yeah, I think it's pretty big, plus I believe most of these packages
require
>openssl and other huge add-ons to run. The basics of public-key
>cryptography, however, are pretty simple, so I think it'd be possible to
>make a small (a few K, perhaps) binary that would
> On 12/3/01 at 4:54 PM, Charles Steinkuehler <[EMAIL PROTECTED]>
> wrote:
>
> > Hmm...looks like a new file format, smells like a new file format...
>
> Bah. Not really. The file "format" is all in the *.lrp package, and
> the package contents remain the same. Just give it a new wrapper,
> cal
On 12/3/01 at 4:54 PM, Charles Steinkuehler <[EMAIL PROTECTED]>
wrote:
> Hmm...looks like a new file format, smells like a new file format...
Bah. Not really. The file "format" is all in the *.lrp package, and
the package contents remain the same. Just give it a new wrapper,
call it *.srp, an
> You could use the two-file format already used for things like the Linux
> kernel, or if you really wanted, just wrap both files up like this -
> create a standard *.lrp file, then you could wrap it up into a *.srp
> file ("Secure LRP") with a digital signature.
>
> Then the unpackers would have
Charles Steinkuehler wrote:
> Most of the feature issues can be cobbled around by adding more
> .whatever files to the package format, but I'd REALLY like to have
> a way of cryptographically signing packages, in preperation for making
> trusted downloading of packages an available feature at run
David Douthitt wrote:
>About all that can be asked for is a "comment-like" tag that package
>creators use to detail dependencies.
Agreed. That's what I was thinking of - comments for things the
maintainer knows of, with no guarantee that its accurate or comprehensive.
And I see what you mean
> > Should we maybe start a sub-project to work on a new packaging format?
I've
> > got a lot of various ideas on possible formats and features, but no time
to
> > play with them :<
>
> I have a strong faith in the current format - even if we package up
> "newfangledsoftware 2.2.2" as a *.lrp with
"Angelacos, Nathan" wrote:
> One question, though - What about adding a "Requires" tag?
> snort.lrp and tcpdump.lrp may both require libpcap.lrp
> newfangledsoftware 2.2.2 with glibc 2.1 requires glibc 2.1,
> and might segfault under 2.0.7.
>
> Maybe there's no way to automate the requires bi
David Douthitt wrote:
> I have a strong faith in the current format - even if we package up
> "newfangledsoftware 2.2.2" as a *.lrp with glibc 2.0, it'll still work
> in that LRP 2.9.4 somebody's running.
>
> If we add a new file (*.desc) to the /var/lib/lrpkg directory, the
> package STILL works
Charles Steinkuehler wrote:
>
> > Here's the keywords my script understands:
> >
> > keywords["Name"]=1
> > keywords["Version"]=1
> > keywords["Release"]=1
> > keywords["Packager"]=1
> > keywords["Packaged"]=1
> > keywords["Keywords"]=1
> > keywords["Description"]=1
> > keywords["URL"]=1
> > keyw
Charles Steinkuehler wrote:
>How do your fields compare against those stored by rpm & deb?
>
A quick cruise over to debian and rpm.org produced this for me
(Sorry, Dave, if I'm speaking out of turn)
rpm debianDave
NamesourceName
Version Version
> Here's the keywords my script understands:
>
> keywords["Name"]=1
> keywords["Version"]=1
> keywords["Release"]=1
> keywords["Packager"]=1
> keywords["Packaged"]=1
> keywords["Keywords"]=1
> keywords["Description"]=1
> keywords["URL"]=1
> keywords["License"]=1
> keywords["Group"]=1
>
> and p
"Angelacos, Nathan" wrote:
>
> Jack Coates <[EMAIL PROTECTED]> wrote:
>
> >And for this reason I'm thinking that versioning in the filename is a
> >convenient nice-to-have.
It would. But with an 8 character limit, what about programs like nmap,
which is has version numbers like 2.3BETA10 - whi
Jack Coates <[EMAIL PROTECTED]> wrote:
>And for this reason I'm thinking that versioning in the filename is a
>convenient nice-to-have. If the version and author attributes are kept
>on the web server that should be enough to enable accurate downloads,
>though there are still troubleshooting issu
On Mon, 3 Dec 2001, David Douthitt wrote:
> On 12/2/01 at 9:59 PM, Jack Coates <[EMAIL PROTECTED]> wrote:
>
> > there are two problems with this scenario:
> > 1) It's a PITA to look all over the place for packages.
> > The leaf.sf.net site is not exactly good guidance since
> > the packages page
On 12/2/01 at 9:59 PM, Jack Coates <[EMAIL PROTECTED]> wrote:
> there are two problems with this scenario:
> 1) It's a PITA to look all over the place for packages.
> The leaf.sf.net site is not exactly good guidance since
> the packages page is empty and they're all under pub/
> which isn't link
20 matches
Mail list logo
