Tim Wegner wrote:
2. One irritation it would be nice to fix (though it may go beyond the
quick upgrade to EigerStein2Beta philosophy) would be to
somehow extend the 256 character limit of the syslinux.cfg
APPEND= line. When I add a second drive to PKGPATH and add
serial support, I'm over
A couple of requests.
1. It would be useful to integrate one the extended scripts unto
DachStein. (You probably already thought of this :-)
snip
So it would be nice for DachStein to be EigerStein2beta workalike
(e.g. with the network defaults as I mentioned above) with the
added
Dale Long wrote:
The extra package elements you are describing here might make a flexible
way to implement a configuration template for text based and web based
configuration.
Eg: pkg.web or pkg.setup-template
Took me a minute to realize what you were saying but that is
(almost)
I propose the following updates to packages, and would like to start
using them:
pkg.sh Shell script which takes a
parameter - one of:
preinst postinst prerem postrem
...executed by apkg at times indicated
pkg.descConf file describing package:
I propose the following updates to packages, and would like to start
using them:
pkg.sh Shell script which takes a
parameter - one of:
preinst postinst prerem postrem
...executed by apkg at times indicated
pkg.descConf file describing
Charles Steinkuehler wrote:
I think the pkg.req should be based on a functionality list, not a simple
package name. There should also be some way to differentiate versions
and/or functionality. For instance, it's probably important to be able to
tell the difference between glibc versions,
David Douthitt, 2001-07-11 10:42 -0400
Charles Steinkuehler wrote:
I'd like to see a 'ground-up' effort including the new c libraries,
2.2/2.4 kernel support, the new packaging system (likely apkg on
steroids), and other enhancements. I don't see any reason to tie
these changes to
I think the pkg.req should be based on a functionality list, not a
simple
package name. There should also be some way to differentiate versions
and/or functionality. For instance, it's probably important to be able
to
tell the difference between glibc versions, and between POSIXness,
David,
Would it be a good idea for us to follow the LSB 1.0 specs?
http://www.linuxbase.org/
https://sourceforge.net/projects/lsb
AFAIK, we can't follow LSB and still fit on a floppy, but we should probably
try to not break any LSB rules. It may be possible to make a superset of
some LEAF
Charles Steinkuehler wrote:
I'd like to see Dachstein be a fairly straight-forward update to the
Materhorn/Eiger series disks. I hope to get this done in the near term ...
This a would be worthwhile.
A couple of requests.
1. It would be useful to integrate one the extended scripts unto
On Wed, 11 Jul 2001, David Douthitt wrote:
For me, I almost hesitated to put that in - but the way I build packages
(main binary in bin.lrp, needed dynamic libraries in libX.lrp) adding
requirements is a big win.
However, these are my goals:
1. Simplicity
2. Simplicity
3. Simplicity :-)
11 matches
Mail list logo
