On Mon, 2006-08-21 at 20:42 +0200, Eric Spakman wrote:
> Hi Natanael,
> >>
> >> Couple of questions, while we're doing the 3.0 flag day, would it be OK
> >> if we made the package dependancies explicit, not part of the help
> >> file?
> >>
> >> /var/lib/apkg/.depend
> >>
> >
> > I have this implem
Hi Natanael,
>>
>> Couple of questions, while we're doing the 3.0 flag day, would it be OK
>> if we made the package dependancies explicit, not part of the help
>> file?
>>
>> /var/lib/apkg/.depend
>>
>
> I have this implemented in apk-tools. Take a look there how it can be
> implemented and feel
On Sat, 2006-08-19 at 01:32 -0700, Paul Traina wrote:
> Eric & KP,
>
> Looks nice, been trying to catch up on things...
>
> Couple of questions, while we're doing the 3.0 flag day, would it be OK
> if we made the package dependancies explicit, not part of the help file?
>
> /var/lib/apkg/.depend
Cool. I'm heading out to the desert for 2 weeks, I'll check back in
once I have come home and washed all the dust off and regained my sanity.
Paul
-
Using Tomcat but need to do more? Need to support web services, security?
Hi Paul;
Am Samstag, 19. August 2006 19:01 schrieb Paul Traina:
> Your call, but the stuff in the help file isn't formalized and it isn't
> validated in any way since it was always human input.
The help stuff is as formal as a .depend would be, the first is generated from
buildtool.cfg, the latt
Your call, but the stuff in the help file isn't formalized and it isn't
validated in any way since it was always human input.
When are you guys shooting for a 3.0 alpha test release? I just whacked
together stuff for burning man based on 2.4.2 even though that's a bit
creaky because I wasn't s
Hi Paul,
>Eric & KP,
>
>Looks nice, been trying to catch up on things...
>
>Couple of questions, while we're doing the 3.0 flag day, would it be OK
>if we made the package dependancies explicit, not part of the help file?
>
That would be a good idea.
>
>The dependencies should theoretically be r
Eric & KP,
Looks nice, been trying to catch up on things...
Couple of questions, while we're doing the 3.0 flag day, would it be OK
if we made the package dependancies explicit, not part of the help file?
/var/lib/apkg/.depend
which would contain a list of packages that the current package depe
On Fri, 2006-06-16 at 11:27 +0200, Eric Spakman wrote:
> Hello Natanael,
>
> >apk-tools create the package listing on the fly. Something like:
> >
> >tar -ztf package.apk > var/db/apk/package/CONTENTS
> >tar -zxf package.apk
> >
> A question.
> How do you handle config files added by an user? To g
Hello Natanael,
>apk-tools create the package listing on the fly. Something like:
>
>tar -ztf package.apk > var/db/apk/package/CONTENTS
>tar -zxf package.apk
>
A question.
How do you handle config files added by an user? To give an example:
A package like hostapd contains a directory /etc/hostap
On Tue, 2006-06-13 at 16:32 +0200, Jaap Eldering wrote:
> >
> > > It shouldn't impossible do that in shell with diff/top. But I guess the
> > > only sane thing would be to write a C app for that. Maybe later...
>
> In the GNU diffutils there is the (I think fairly unknown) program
> sdiff, which a
On Tue, 2006-06-13 at 16:32 +0200, Jaap Eldering wrote:
> In the GNU diffutils there is the (I think fairly unknown) program
> sdiff, which allows one to diff to files side by side and merge them.
>
> I have looked into it once, also for some script I wrote for merging
> changes while updating to
On Mon, Jun 12, 2006 at 03:06:10PM +0200, Eric Spakman wrote:
> Hello Nataneal,
>
> >> Cool, but user changes are lost if you choose the option to update the
> >> config file. I was more thinking about something that updates the new
> >> config file with changes from the old one, which is probably
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Natanael Copa wrote:
> On Mon, 2006-06-12 at 20:52 +0200, Eric Spakman wrote:
>> Hi Nataneal,
In most cases (HD/Flash/Floppy) the first device is the backup device,
having a seperate variable would only introduce redundancy. But I was
th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Spakman wrote:
>>> I'm not sure if it's obvious if
>>> backup fails that the above entry can be the fault, if a note is added
>>> in the leaf.cfg file that the first entry is the backup device in the
>>> PKGPATH
>>> it could be clearer. But I'm s
Hi Nataneal,
>>> I'd suggest to add a CFGDEV and default it to:
>>>
>>>
>>> CFGDEV=$PKGPATH
>>>
>>>
>>> Then can the user choose himself.
>>>
>>>
>> Good suggestion didn't thought about that, but PKGPATH can be a list
>> and the first entry can still be a CDROM.
>
> then you could default CFGDEV t
On Mon, 2006-06-12 at 20:52 +0200, Eric Spakman wrote:
> Hi Nataneal,
> >>
> >
>
> >> In most cases (HD/Flash/Floppy) the first device is the backup device,
> >> having a seperate variable would only introduce redundancy. But I was
> >> thinking about adding a menu entry where an user can select t
Hi Nataneal,
>>
>
>>> But the, what happens if you try to upgrade apk-tools? after
>>> apk_delete, there are no apk_add to install the new package. I solved
>>> it by first unpacking the new package, then compare the lists and
>>> remove all files that are in old list but not in new list. (reverse
On Mon, 2006-06-12 at 15:37 +0200, Eric Spakman wrote:
> Hi Nataneal,
> > But the, what happens if you try to upgrade apk-tools? after apk_delete,
> > there are no apk_add to install the new package. I solved it by first
> > unpacking the new package, then compare the lists and remove all files
>
Hi Nataneal,
>> Correct, although it's somewhat difficult to remove a package without a
>> .list file.
>>
>
> apk-tools create the package listing on the fly. Something like:
>
> tar -ztf package.apk > var/db/apk/package/CONTENTS tar -zxf package.apk
>
That can also be implemented in Bering-uClib
Hello Nataneal,
>> Cool, but user changes are lost if you choose the option to update the
>> config file. I was more thinking about something that updates the new
>> config file with changes from the old one, which is probably almost
>> impossible ;)
>
> Nothing is impossible. The "impossible" jus
On Mon, 2006-06-12 at 14:12 +0200, Eric Spakman wrote:
> Hello Nataneal,
hi.
> > Now, run a utility that:
> >
> >
> > diff -u foo.conf foo.conf.new
> >
> > and ask: would you like to: 1) keep the old config.
> > 2) replace old with new.
> > 3) do nothing.
> >
> >
> > conf=foo.conf case $choice in
On Mon, 2006-06-12 at 14:04 +0200, Eric Spakman wrote:
> Hello Nataneal,
hi hi
> >> Currently we create a .sha1 file for every package instead of
> >> one big sha1 file. I played with it a few days and this implementation
> >> seems to work most flexible, although I can't rememember all the reason
Hello Nataneal,
>> That would be nice, but could be implemented afterwards. The question
>> is if it's really needed. If the changes between package
>> versions/revisions are compatible, it's just a matter of replacing the
>> package. If the changes are incompatible, the question is if a 3-way
>>
Hello Natanael,
> Have you seen etc-update in gentoo or mergemaster in freebsd? Can be
> nice to have a look so you can get som inspiration ;)
Yes, I've tried gentoo and really liked the idea of etc-update
> diff -u foo.conf foo.conf.new
>
> and ask: would you like to:
> 1) keep the old config.
Hello Nataneal,
>>
>
> [ cutted a few lines ]
>
>> Correct, although we took a slightly different direction. The reason we
>> use .local files is that when you boot the /etc directory grows with
>> every installed package (files are added), so the sha1sum is calculated
>> again and again for the s
On Mon, 2006-06-12 at 11:19 +0200, Cédric Schieli wrote:
> > [...] The current system is really very simple and
> > doesn't use extra tools like diff and patch. Besides config files (text
> > files) compress very good so the result will probably be a lot smaller
> > than introducing new requiremen
On Mon, 2006-06-12 at 10:26 +0200, Cédric Schieli wrote:
> As pointed out somewhere in this list, documentation is often
> contained in config files. Merging when there are no incompatible
> changes gives you an opportunity to get new "doclets". If changes are
> incompatible, let's spawn a shell f
On Mon, 2006-06-12 at 09:24 +0200, Eric Spakman wrote:
> Hello Cedric,
> >
> > What about a 3-way diff tool during upgrade process ? We would then
> > have a really upgradable system.
> >
> That would be nice, but could be implemented afterwards. The question is
> if it's really needed. If the cha
On Mon, 2006-06-12 at 11:39 +0200, Eric Spakman wrote:
> Hello Nataneal,
[ cutted a few lines ]
> > This leads us to: create checksums (or save "status") of everything
> > in /etc during package installation (during boot in other words). This is
> > the "default", or "pristine" database. Do your
Hello Cedric,
>> Not sure, now that we tag the sources it should be easier to checkout a
>> specific version. Making a seperate branch would introduce extra work
>> and take extra time we don't have..
>
> Yes, but what about 2.4.x bugfix releases while this long process of
> upgrading every packa
Hello Nataneal,
>> It works as follows (somewhat simplified):
>> -At startup (pre-init) the sha1-sums of files listed in a
>> .local
>> file are calculated and saved in a .sha1 file. The files listed
>> in .local are user changable files like config files and f.e.
>> ssh-keys -At backup time the
On Sun, 2006-06-11 at 23:39 +0200, Eric Spakman wrote:
> Hello list,
>
> The Bering-uClibc crew is working on a new config/backup system. In this
> system config changes are no longer saved in the package itself but in a
> seperate "configdb" package. The same is true for modules, which are saved
> > I meant a timeline (TODO list ?) for an upgraded uClibc toolchain.
> > Thus we can start rebuilding and testing ;)
> > As buildtool now permit using a local checkout, wouldn't be useful to
> > have a dedicated cvs branch for that work to be done ?
> >
> Not sure, now that we tag the sources it
Op Ma, 12 juni, 2006 10:26 am schreef Cédric Schieli:
>> I have an image I can send you this evening (UTC) when I'm home. If
>> there is more demand, maybe it can be placed somewhere on the LEAF site.
>>
>
> I'll be there ;)
>
Ok :))
>
>> Not yet, it depends on everyones free time ;)) The move to
> I have an image I can send you this evening (UTC) when I'm home. If there
> is more demand, maybe it can be placed somewhere on the LEAF site.
I'll be there ;)
> Not yet, it depends on everyones free time ;)) The move to a new config
> system and/or uClibc upgrade touches every package setup in
Hello Cedric,
> Hi Eric,
>
> That sounds great.
> Is there already something we can test/hack ?
I have an image I can send you this evening (UTC) when I'm home. If there
is more demand, maybe it can be placed somewhere on the LEAF site.
> Any idea on the timeline, especially for the (long awaite
Hi Eric,
That sounds great.
Is there already something we can test/hack ?
Any idea on the timeline, especially for the (long awaited) uClibc upgrade ?
What about a 3-way diff tool during upgrade process ? We would then
have a really upgradable system.
Regards,
Cedric
2006/6/11, Eric Spakman <
38 matches
Mail list logo
