Re: [Freedos-user] FreeDOS Updater v0.52

2008-01-05 Thread Mateusz Viste
On Saturday 05 January 2008, Mateusz Viste wrote:
 If you would like to have a FDUPDATE's localisation in your language,
 please translate the FDUPDATE.EN file and send it to me, that way I will be
 able to include it in the next release.

Hello all,

I got a german translation from Flo, therefore german is not needed 
anymore ;-)

Mateusz Viste

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-04 Thread Jim Hall
I think we've covered the important points so far in our discussion.
I've started to capture the thread in a new changes to the software
list document, using as much copy/paste from this discussion as
possible. That document can be the start of a spec for (a) what the
new software list will do  look like (including data output format,
etc.) and (b) what the FreeDOS updater will read.

Hope to have it done this afternoon if I can also work on it during
lunch. Will post it on www.freedos.org for general discussion.

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-04 Thread Aitor Santamaría
Great!

2007/12/4, Jim Hall [EMAIL PROTECTED]:
 I think we've covered the important points so far in our discussion.
 I've started to capture the thread in a new changes to the software
 list document, using as much copy/paste from this discussion as
 possible. That document can be the start of a spec for (a) what the
 new software list will do  look like (including data output format,
 etc.) and (b) what the FreeDOS updater will read.

 Hope to have it done this afternoon if I can also work on it during
 lunch. Will post it on www.freedos.org for general discussion.

 -
 SF.Net email is sponsored by: The Future of Linux Business White Paper
 from Novell.  From the desktop to the data center, Linux is going
 mainstream.  Let it simplify your IT future.
 http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-03 Thread Jim Hall
On 12/2/07, Aitor Santamaría [EMAIL PROTECTED] wrote:
 Hello,

 2007/12/2, Jim Hall [EMAIL PROTECTED]:
  There is an important difference. What I put in the general archive on
  ibiblio is a mirror of other people's work. For most programs, they
  already have another primary location, and (license permitting) I'm
  just putting it on ibiblio so that it has at least a 2nd place to live
  (for example, in case the original site goes down or otherwise becomes
  unavailable.) Users should still be able to download the original
  program in its original archive from ibiblio, AND IT SHOULD BE
  IDENTICAL TO WHAT WAS ORIGINALLY RELEASED BY THE AUTHOR/MAINTAINER.

 But it is not even true for the packages in the distributions,
 compared to the ones created by us (for which I'm grateful, they are
 better!).


Just to be clear: what I am trying to say is that files put in
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/
should be assumed to be pkgs, not the originally zip file release of
the program. And we should consider changing the names of these pkgs
so they have a FDP or PKG extension.

But files that are in any other directory on ibiblio (like say
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/
or
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/
should assumed to be a mirror of the author's original zip file release.

I don't want to re-zip or re-package any files that are in the
mirror areas. I consider that to be inappropriate, as it confuses
users to what was the actual original released file. But I think it's
presumed to be ok to re-package programs for inclusion in a
distribution (to be sure they have the correct dir structure, etc) so
that is why I mak

 Perhaps it could be a good idea that besides any ZIP (untouched) there
 would be a file with the same name, but some extension, like LSM or
 another, that would contain all those extra info needed for the
 packager: the version or date to compare, the mapping of files onto
 the pkg structure, and other useful info (such as post-install script
 that I mentioned too). Actually, this info file could be the XML that
 Jim suggested, a quite extensible idea (hopefully XMLs are easy to
 read in C?).

If the zip file contains an LSM file, I usually unzip it next to the
original zip file ... just for this reason, so users would know what
was contained in the file, and to make things easier on the person
creating a pkg.


  Mateusz  I just had a brief off-list discussion where I suggested we
  may want to change how FDPKG manages packages. One thing we may want
  to do is have all pkg files have a PKG or FDP (FreeDOS Package)
  extension, rather than keep the zip extension, even though the pkg
  file is just a zip file with a particular directory structure.
  Changing the extension would be a good way to implicitly declare that
  the pkg file is not the original release zip file (4dos759.zip 
  4dos759.fdp, for example.)

 Oops, I hadn't read this when I wrote my previous mail. Needless to
 say, I like the idea ;-)

  It might be a good/interesting idea, though, to add an option to
  FDUPDATE to tell it to read/unzip the packages in-place (i.e. assume a
  local repo) rather than wget them to a local cache. Obviously, that
  works well when the repo is local, but not so well when the repo is on
  a web server somewhere.

 You're talking (I guess?) as some type of repository type, that
 could be either internet or local. Perhaps the address could give
 the clue:
 http://www.freedos.org/
 file://d:\updates

Nice solution, I like that.

-jh

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-03 Thread Jim Hall
On 12/2/07, Aitor Santamaría [EMAIL PROTECTED] wrote:
[...]
 Following the idea I exposed before, you could even have locally a
 folder called:

 C:\FREEDOS\3RDPARTY\...

 where it would unpackage all that is not packaged on the new structure
 (in the words before, being a ZIP and not a FPF).

Hmm... not sure I like that idea. If it's in the distribution, it
should be in a package. And I don't think the installer or FDPKG
should try to do this either - these should just report the file is
not in pkg format and not install it (there's no pkg install tracking,
etc)

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-03 Thread Jim Hall
On 12/2/07, Aitor Santamaría [EMAIL PROTECTED] wrote:
 As I see it, the fact that some DOS software is mirrored at ibiblio's
 FreeDOS repository is a privilege, not a nice present.
 Thus, it could be an idea that there is some kind of FreeDOS logotype
 test (LOL ;-)) meaning that some programs have passed the minimum
 requirements of:
[...]

See my other email. The mirror areas of ibiblio should remain mirror
areas, and not a FreeDOS logo test. Besides, I had made arrangements
with some authors (and still do) to host their primary release zip
file on ibiblio because they did not have a web page to host it. In
these cases, it already breaks the suggestion that placement on
ibiblio is a privilege.

But programs that are in the distributions can be assumed to be
re-zipped pkgs, especially so if we choose to rename them with FDP or
PKG.

 I thought of the second because the programmer could encode in that
 LSM the condition to run certain Post-Install script, that would be
 run after the package is installed. The extended LSM could host
 other information, that we might not exploit at this moment, but maybe
 in the future. Things like: dependencies, path to executable, path to
 a HTML-Help file (for automatic Help update), etc.
 Then there's the decission whether the FreeDOS package would be able
 to deal with these special FPF files (and deal with the versioning
 stuff, post-install script, maybe dependencies), and for standard ZIP
 packages, well, just the basic (there exists XXX.ZIP with date YYY,
 newer than current XXX.LSM, install?).

Interestingly, at one point on FDPM we had considered adding
dependencies and post-install tasks a-la the RPM spec (%dependencies%
and %pre% and %post% sections after the End in the LSM.) But we
never followed up on it while I worked on FDPM.


  3. We may (at some later date) choose to change the FreeDOS pkg
  directory layout. As of today, no suggestions to do this have been
  made, but a year from now it's possible that we may want to change it.
  I don't want to re-zip everything on ibiblio to meet the new pkg
  standard.

 Perhaps it is the moment to see if the pkg structure needs a review or
 not. We could discuss about it, and settle certain FreeDOS directory
 structure 1.0, so that programs are based on it.

 A clever idea that Microsoft does (for example, to allow locale in
 filenames, C:\Program Files is, in my system, C:\Archivos de
 Programa\) IIRC is to use a kind of location variable, so that for
 example, %10 would be Program Files, %11 would be Windows folder, etc.
 It would be certainly quite a lot of more work, but it could be that
 the ZIP (or FPF) does NOT have directories, but has instead a mapping
 file:
 \DISKCOPY.001   =  %12\DISKCOPY.EXE
 (and in turn, %12 could be standarised to C:\FREEDOS\BIN by the
 packager program).

If we're open to discussing the pkg format, I'd like to suggest 3 things:

1. adherence to the directory layout (already defined, but probably
not well known)

2. move the LSM file out of the zip file archive, and into the zip
file comment header. This makes it easier for programs built using zip
file tools to easily read the LSM header without having to unzip part
of the archive just to read a single APPINFO/__.LSM file.

3. adherence to the LSM file format. We have a lot of LSMs out there
now that don't follow the LSM format very well. We should either move
back to what the LSM spec actually says, or agree that we're
abandoning it and choose some other file format for pkg info.




-jh

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-03 Thread Eric Auer

Hi Jim,

 Interestingly, at one point on FDPM we had considered adding
 dependencies and post-install tasks a-la the RPM spec (%dependencies%
 and %pre% and %post% sections after the End in the LSM.) But we
 never followed up on it while I worked on FDPM.

The current implementation (by Blair) is that FDPKG looks for
certain filenames in the zipped package. Those fixed-name files
can describe: Things to do for updates (as a batch file, can for
example delete the old EXE if the new version uses a COM), things
for postinstall (batch), things for uninstall (batch afair) and
dependencies (machine readable text file).

  \DISKCOPY.001   =  %12\DISKCOPY.EXE
  (and in turn, %12 could be standarised to C:\FREEDOS\BIN by the
  packager program).

I think that would be overdoing things. We should be happy if
we get more downloads available in the fine existing fdpkg zip
format for now :-).

 2. move the LSM file out of the zip file archive, and into the zip
 file comment header. This makes it easier for programs built using zip
 file tools to easily read the LSM header without having to unzip part
 of the archive just to read a single APPINFO/__.LSM file.

Is the comment header really easier to unzip than a file? I had
the impression that zip libraries like for example the one used
in htmlhelp focus on unzipping files to files or buffers anyway.

I agree to 1. and 3. - we should stick to the existing and
proven directory structure and LSM file format :-). Yet it
would be okay to extend LSM, for example to have 2 fields
for URLs, one for a general project page and one for the
exact file download of the fdpkg (!) zip of this version.

Eric :-)



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-03 Thread Aitor Santamaría
Hello,

2007/12/3, Jim Hall [EMAIL PROTECTED]:
 On 12/2/07, Aitor Santamaría [EMAIL PROTECTED] wrote:
 But programs that are in the distributions can be assumed to be
 re-zipped pkgs, especially so if we choose to rename them with FDP or
 PKG.

That is good. Then you could go along with an standard. Perhaps
re-versioning the packing howto. Reviewing other things, as the must
of including the LSM file somewhere (as in the header), and the
possible extensions to the LSM (see below).

 Interestingly, at one point on FDPM we had considered adding
 dependencies and post-install tasks a-la the RPM spec (%dependencies%
 and %pre% and %post% sections after the End in the LSM.) But we
 never followed up on it while I worked on FDPM.

What I am then a bit lost is, what and where is the use of the XML
file that was mentioned in other parts of the conversation?

 If we're open to discussing the pkg format, I'd like to suggest 3 things:

 1. adherence to the directory layout (already defined, but probably
 not well known)

 2. move the LSM file out of the zip file archive, and into the zip
 file comment header. This makes it easier for programs built using zip
 file tools to easily read the LSM header without having to unzip part
 of the archive just to read a single APPINFO/__.LSM file.

 3. adherence to the LSM file format. We have a lot of LSMs out there
 now that don't follow the LSM format very well. We should either move
 back to what the LSM spec actually says, or agree that we're
 abandoning it and choose some other file format for pkg info.

The (2) idea is great, specially if it can be extracted using a C API too!
As for the rest, I would simply re-version the how-to that talks about
packing (the contribution howto?).

Aitor

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-02 Thread Jim Hall
  One more thing: I think the pkgs and spkgs for the update server
  should be assumed to be different than the zip files that we upload to
  ibiblio. A pkg and spkg have a particular meaning; they contain a
  particular directory structure.

 You are right, but it would be good if we could move towards a point
 where all files have that directory structure. Otherwise, it will be
 the exception, not the rule, that a downloaded zip file can be used
 for updating. For all normal files, people now are forced to unzip
 to a temp directory and spend time to sort the files to put them in
 the right directories in their installed freedos.

It's not realistic to assume we will be able to have *every* zip file
on the ibiblio archive to use the FreeDOS pkg directory structure.
There are a few problems here:

1. Not all developers care about FreeDOS pkg structure. And it would
be inappropriate of me to re-zip their release into a FreeDOS
pkg-compatible structure. (It would be ok to create a pkg to put on
the update server, but it is not ok to re-zip someone else's work
before putting it in the general archive.) Also note that sometimes we
put zip files on ibiblio that cannot be included on the FreeDOS
distribution because they are not free for all, but are useful for
some. The license for these non-free programs may prohibit
repackaging.

2. There are historical versions on ibiblio. Does your suggestion
imply that users should be able to find a historical version of a
program that interests them, and should be able to install it using
the pkg directory structure?

3. We may (at some later date) choose to change the FreeDOS pkg
directory layout. As of today, no suggestions to do this have been
made, but a year from now it's possible that we may want to change it.
I don't want to re-zip everything on ibiblio to meet the new pkg
standard.

4. Others who roll their own distro for themselves or for a distro
they make available to others may not want to use our pkg directory
layout, but instead go with something slightly different.


But of all the above, #1 is the most significant and will be the
reason we will not get 100% of all zip files into pkg format. It's a
pipe dream to think otherwise. But I think we can assume it's ok for
packages that are put on the update server ()



  But the FDUPDATE program will be downloading these files using
  wget to a DOS filesystem.

 Suggestion: wget -O choicex.zip http://foo/bar/choice-4.4-binary.zip

 This also makes sure that you have a static name of the
 downloaded file (does not contain a version number) and also
 a readable name (does contain the full name choice) after
 the download and a readable name including a readable version
 number on the server :-).

 Remember that it is useful if people can find a package with
 google. Bonnie probably has a lot of experience with this
 when she tried to find new downloads of various packages...
 She would not have found a dkcp0815.zip when looking for
 freedos diskcopy.

Your suggestion works well when the package title is 7 characters or
less. But you give an example of a package title that is 8 characters
(DISKCOPY). Also DISKCOMP, CUTEMOUSE, GRAFTABL, FASTHELP, FDSHIELD,
FDXMS286, GRAPHICS, LBACACHE, UNFORMAT ... all from the Base list. And
FDUPDATE. :-) Also be aware of potential confusion between HIMEM and
HIMEMX, which are both different packages.

But since we don't seem to have pkg dependencies in FreeDOS pkgs, I
suppose there is no reason for FDUPDATE to save the pkg to a
recognizable filename. After all, it's only downloading into its local
cache, and probably can be safely deleted from the cache after all
updates are applied. So FDUPDATE could maintain an internal counter of
files downloaded, and do this:

wget -O 0001.ZIP http:///1.1/updates/pkgs/base/choic44x.zip


You have room for 99,999,999 packages downloaded at once before you
run out of (numerical) namespace. Not likely to reach this, but
FDUPDATE could always switch to an alpha-numeric namespace if we think
this will be a limitation. :-)


-jh

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-02 Thread Eric Auer

Hi Jim,

 1. Not all developers care about FreeDOS pkg structure.
 And it would be inappropriate of me to re-zip their release

Would it? I mean if you want the original structure, you
download from the developer's homepage. When I look at
getdeb.net and rpmfind.net, I see packages which follow
a distro and ignore the developer all over the place, but
of course I also get URLs where I can get original TGZs.

FreeDOS is not only a kernel, it is also a distro, and the
only way you can ship a package as part of the distro is
to put it in FreeDOS pkg compatible structure first :-).

 put zip files on ibiblio that cannot be included on the FreeDOS
 distribution because they are not free for all...

You are right. The updater can make use of extra nonfree
repositories outside ibiblio, while our ISOs gotta be free.

 2. There are historical versions on ibiblio. Does your suggestion
 imply that users should be able to find a historical version of a
 program that interests them, and should be able to install it using
 the pkg directory structure?

No, not at all. Sorry for being unclear about that point. I was
only suggesting to repackage new versions in fdpkg compatible
format before uploading them to ibiblio. My assumption is that
the installer only automates getting the newest version and only
if it is newer than at least FreeDOS 1.0 (or maybe even 1.1).
Older versions do not have to be repackaged and I assume that a
user who wants to install them will do so manually without using
the updater :-).

 I don't want to re-zip everything on ibiblio to meet the new pkg
 standard.

The standard is not new - I only suggest to re-zip everything
which will be part of FreeDOS 1.1, because there is not other
choice. You need zips in fdpkg format for every single package
which will be on the ISO, and we need helpers for that task.

For the beta9 and 1.0 distros, Bernd and Blair had to do most
of this work themselves, and it is a lot of work because there
are many packages and because quite a few are not already in
fdpkg format when you download them from the developer's page.

And whenever I want a version of a package which is not on one
of the ISOs, I run the risk of having to unzip to a temp dir
and putting each file into a nice place manually to install,
so at least I myself would appreciate if more things on ibiblio
become available in fdpkg format in the future. As said, that
only affects future updates, not archived versions :-). Things
like Arachne have been using adjusted directory structures and
can stay like that: It uses %dosdir%/arachne/... because putting
all arachne files in bin/ would overwhelm bin/, yet there are
fdpkg compatible bin/arachne,bat and appinfo/arachne.lsm :-).

 4. Others who roll their own distro for themselves or for a distro
 they make available to others may not want to use our pkg directory
 layout, but instead go with something slightly different.

Even those will have an easier life when all packages are in one
unified package format before they start to roll them into their
distro's preferred format. At the moment, packages at ibiblio are
often in unknown / arbitrary format, and you have to look at every
single package before you can risk unzipping it in %dosdir%.

 But of all the above, #1 is the most significant and will be the
 reason we will not get 100% of all zip files into pkg format.

As said - for every single distro ISO of FreeDOS, be it in the past
or in the future, somebody first had to put one version of each of
the 100% of all packages into fdpkg format before putting it on ISO.

  Suggestion: wget -O choicex.zip http://foo/bar/choice-4.4-binary.zip

 Your suggestion works well when the package title is 7 characters or
 less. But [...] Diskcopy [...]

You are right. Yet pkg/choice.zip is still a lot better than
illegible shorthands like dkcp815x.zip :-). And package titles
are never more than 8 chars long for the simple reason that the
title is usually the name of the main executable which has an
8+3 style name :-). So my next suggestion is to drop the X and
S suffixes from the name of the zip in the working directory of
the installer :-).

 suppose there is no reason for FDUPDATE to save the pkg to a
 recognizable filename. After all, it's only downloading

You are right, but what I have in mind are people who use the
repository for manual updates. As said, fdpkg zips are much
easier to install than arbitrarily formatted zips. Humans will
NOT be happy about http...choic44x.zip when they google for them.
They WILL be happy about http...choice-44-binary.zip though :-).

Remember that it is far from normal that FreeDOS installations
are on networked computers. Systems like Ubuntu and Windows now
almost force you to have fast (!) internet for updates but for
DOS many users will be interested in downloading files using
another PC or another operating system and then later, offline,
using them to update their DOS. Remember that there are no INF
files for FreeDOS, so users 

Re: [Freedos-user] FreeDOS Updater

2007-12-02 Thread Jim Hall
On 12/2/07, Eric Auer [EMAIL PROTECTED] wrote:

 Hi Jim,

  1. Not all developers care about FreeDOS pkg structure.
  And it would be inappropriate of me to re-zip their release

 Would it? I mean if you want the original structure, you
 download from the developer's homepage. When I look at
 getdeb.net and rpmfind.net, I see packages which follow
 a distro and ignore the developer all over the place, but
 of course I also get URLs where I can get original TGZs.

Yes, it does matter. Your reply dropped the part of my email that had
the important point, so allow me to re-paste it here:

It would be ok to create a pkg to put on the UPDATE server, but it is
not ok to re-zip someone else's work before putting it in the GENERAL
archive.


(emphasis added)

There is an important difference. What I put in the general archive on
ibiblio is a mirror of other people's work. For most programs, they
already have another primary location, and (license permitting) I'm
just putting it on ibiblio so that it has at least a 2nd place to live
(for example, in case the original site goes down or otherwise becomes
unavailable.) Users should still be able to download the original
program in its original archive from ibiblio, AND IT SHOULD BE
IDENTICAL TO WHAT WAS ORIGINALLY RELEASED BY THE AUTHOR/MAINTAINER.
Else, it would confuse which was the version that the author had
actually released. That's why when I reply to announcements about new
program versions on this list, I consistently say I mirrored your
release on ibiblio, and why I no longer convert rar files to zip
files.

It would also mean the general archive on ibiblio was no longer a
mirror site - and it needs to remain a mirror site.

Case in point: 4DOS 7.59 is available from http://www.4dos.hit.bg/ - I
have mirrored this release on ibiblio at
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/4dos/

But if you look at the 4dos759.zip file, it doesn't contain any pkg
structure. It's just a zip of the files that make up 4DOS 7.59,
without any directories. Doc files are mixed with help files and exe
files.

If we were to turn this into a pkg file (to put on the update server,
for example) we would necessarily need to add the pkg directory
structure. But (and this is the important bit) we DO NOT save the new
pkg file as 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/4dos/4dos759.zip.
Instead, we would save it as
http:///1.1/updates/pkgs/util/4dos759.zip. There's an implicit
declaration based on its new location that this is a pkg file, not the
original zip file - even though they happen to have the same name.
It's not ideal, but keeping the zip extension can confuse things when
the original release was also a zip file.

Mateusz  I just had a brief off-list discussion where I suggested we
may want to change how FDPKG manages packages. One thing we may want
to do is have all pkg files have a PKG or FDP (FreeDOS Package)
extension, rather than keep the zip extension, even though the pkg
file is just a zip file with a particular directory structure.
Changing the extension would be a good way to implicitly declare that
the pkg file is not the original release zip file (4dos759.zip 
4dos759.fdp, for example.)

  I don't want to re-zip everything on ibiblio to meet the new pkg
  standard.

 The standard is not new - I only suggest to re-zip everything
 which will be part of FreeDOS 1.1, because there is not other
 choice. You need zips in fdpkg format for every single package
 which will be on the ISO, and we need helpers for that task.

Again, your reply removes the important part of my statement, and
confuses what I originally wrote. I said:

3. We may (at some later date) choose to change the FreeDOS pkg
directory layout. As of today, no suggestions to do this have been
made, but a year from now it's possible that we may want to change it.
I don't want to re-zip everything on ibiblio to meet the new pkg
standard.


As an example, at some later date we may choose to (slightly) change
the definition of a pkg file. Maybe we decide that the LSM file should
not go in APPINFO, but should be included as a zip file comment, so no
pkg file should ever have an APPINFO after that.

IF WE CONVERTED EVERY ZIP FILE ON THE GENERAL ARCHIVE TO PKG FORMAT,
based on the pkg format today, we would be expected to go back and
re-zip every pkg file when we updated the updated pkg format.

But, again, my point in #1 remains the most important point: it would
be inappropriate to re-zip an author's released program into a pkg
format.

   Suggestion: wget -O choicex.zip http://foo/bar/choice-4.4-binary.zip

  Your suggestion works well when the package title is 7 characters or
  less. But [...] Diskcopy [...]

 You are right. Yet pkg/choice.zip is still a lot better than
 illegible shorthands like dkcp815x.zip :-). And package titles
 are never more than 8 chars long for the simple reason that the
 title is usually the name of the main executable which has an
 

Re: [Freedos-user] FreeDOS Updater

2007-12-02 Thread Eric Auer

Hi Jim,

   And it would be inappropriate of me to re-zip their release

Would it be an option to put the fdpkg structured zips in the
same directory or in a subdirectory of the exact mirror copies?
For example 4dos/4dossomething.rar would be in the same dir as
4dos/4dos-something-fdpkg.zip or 4dos/installable/4dos-something.zip?

It would make it easier for users to find the alternative when they
first download the rar and then find out that it is hard to install.

 just putting it on ibiblio so that it has at least a 2nd place to live

Yet we also use ibiblio for non-mirror purposes: We also use it to
store a repository of installable packages. At least for 1.0 we did.

You are right that it is good to have exact mirrors on ibiblio, too.

 may want to change how FDPKG manages packages. One thing we may want
 to do is have all pkg files have a PKG or FDP (FreeDOS Package)
 extension, rather than keep the zip extension...

Please... Do try to help people who want to do manual updates. Do
not try to make their life hard.

 I don't want to re-zip everything on ibiblio to meet the new pkg
 standard [in case the pkg structure standard changes in the future]

I see no possibility to store the packages in a way which would
make it easy to warp them into a new shape when the fdpkg zip file
structure changes, so we can just as well offer fdpkg-of-today-
shaped zips of the current versions until then ;-). As said, there
is no choice, you cannot make an ISO without fdpkg-shaped zips of
all packages.

 IF WE CONVERTED EVERY ZIP FILE ON THE GENERAL ARCHIVE TO PKG FORMAT,
 based on the pkg format today, we would be expected to go back and
 re-zip every pkg file when we updated the updated pkg format.

We would only need at least 1 version of each package in the new
format as soon as we make a distro which uses the new format. I
think automated transforms would be possible. After all, RPM format
has changed in the past, too ;-). Of course we could make fdpkg able
to process both old and new format packages to avoid a lot of work.
Yet we cannot make fdpgk able to install unstructured packages such
as the original all thrown into 1 directory 4dos download, sorry.

 But, again, my point in #1 remains the most important point: it would
 be inappropriate to re-zip an author's released program into a pkg

I agree that having an exact mirror has some added value. As long
as we provide easy to find (naming!) and easy to install (fdpkg
format!) zips on high performance hosting (ibiblio!) as well :-).

 Suggestion: wget -O choicex.zip http://foo/bar/choice-4.4-binary.zip
 The version number needs to be in there somewhere, and I strongly
 believe that we should not simply overwrite older versions with a
 newer version of a pkg, on the update server. That is, packages should
 not be (exe) http:///1.1/updates/pkgs/util/4dos.zip

Correct.

 Packages should be named
 http:///1.1/updates/pkgs/util/4dos759.zip

You misunderstood me. I meant neither 4dos.zip nor 4dos759.zip but
http:///1.1/updates/pkgs/util/4dos-759.zip (and for the source
package spkgs/util/4dos-759.zip) ... As said, this would help users
who manually download packages. I agree that the update server can
have further data to find download URLs, of course. I only say that
this does not remove the need to have human readable and googleable
URLs for fdpkg shaped package downloads :-).

  You are right, but what I have in mind are people who use the
  repository for manual updates. As said, fdpkg zips are much
  easier to install than arbitrarily formatted zips.

 Not sure I understand this. Why would you use FDUPDATE to fetch
 updates, but then decide to not have FDUPDATE install them

What I mean is: Find a package with google, download with any OS,
put on DOS harddisk in any way, then chdir %dosdir% and finally
unzip package. What I want to avoid is: Having to guess that the
update of diskcopy is found in dkcp815x.zip What I also want to
avoid is: Unzipping a file and finding that all files ended up
in the current directory because you accidentally downloaded a
non-fdpkg structured zip instead of a zip with all files in the
right place in the right directories below %dosdir%.

 My suggestion was that FDUPDATE could save the pkg to its
 local cache using its own assigned filename. That allows us to name
 the pkg file whatever we want on the update server (choice-4.4.zip or
 choice-4.4-exe.zip or choic44x.zip ... whatever makes sense to us.)

Sounds good :-)).

  DOS many users will be interested in downloading files using
  another PC or another operating system and then later, offline,

 Then your suggestion brings us back to the suggestion that the
 update server should stick to 8.3 filenames, so that a user may
 easily access them from FreeDOS without having to translate long
 filenames.

No, not at all... What I have in mind is that somebody uses Windows
on PC 1, uses Firefox to download a file, copy it to a diskette
(using a short file name, but this 

Re: [Freedos-user] FreeDOS Updater FreeDOS install

2007-12-02 Thread Eli
What are you exactly getting when typing echo %dosdir%?


OK, took your advice and entered “echo %dosdir%”.
The response is “C:\FDOS”

The subdirectories Appinfo and Packages are as you describe. Appinfo has 142 
*.lsm files and Packages has 225 subdirectories and 232 *.lst files. I got it 
straight now (probably forgot to do “/w | more” after the dir command --- it’s 
been a while since I used DOS). The full installation is just under 400MB.

Thank you, and my apology for being silly.

—Solo Owl




-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-02 Thread Jim Hall
[...]
  If I had a FreeDOS PC that didn't have internet access, but I was able
  to make a CDROM copy of http:///1.1/updates/, then I could set my
  FDUPDATE repo to point to a directory on the CDROM

 That is an interesting suggestion! My suggestions were more about
 updating a handful of packages manually, instead of updating all
 with some sort of patch cd. Yet a patch cd is 1. a nice idea and
 2. can easily use long file names ;-). And of course 3. It would
 be easy to make a script (bash for Linux, batch for Windows) which
 effectively does mmv \*-\*-\*.zip \#1.zip, in our example renames
 all downloads from choice-44-binary.zip to choice.zip ... After such
 a rename step, you have 100% short names even though you had long
 names on www, AND you can easily do this one-liner in DOS:
 (do cdd %dosdir% first...) for %x in (x:*.zip) do unzip %x :-).

 But as said, a patch cd with a 1:1 mirror of the www update
 repository is a nice idea, too. Yet I would absolutely want
 to avoid crippling filenames down to 8+3 just to be able to
 use such a patch cd without LFN driver, at the cost of making
 people unable to google for updated packages.


I guess I had assumed that there would be a set of web pages out there
that listed the updated packages that were available for download. We
can easily create that. I mentioned a few emails ago that I'd like to
convert the software list into a kind of database that happens to
output LSM and HTML (and XML). So I thought it was assumed there'd be
a page out there that you would easily find through Google that lists
the updates.

Example: if I wanted to download the Linux installer package (RPM) of
the AlephOne game, then I would Google for:

 Alephone RPM

And lo, the first result I see is an html page that tells me all about
AlephOne, the version, it's size, contents, ... including a list of
URLs to download it. We would have the same kind of searchable FreeDOS
pkg index, probably on the FreeDOS site, so users would easily be able
to Google for a package.

-jh

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-02 Thread Aitor Santamaría
Hello,

I am going to give a bunch of ideas, I hope any of those is of some use.

2007/12/2, Jim Hall [EMAIL PROTECTED]:
   One more thing: I think the pkgs and spkgs for the update server
   should be assumed to be different than the zip files that we upload to
   ibiblio. A pkg and spkg have a particular meaning; they contain a
   particular directory structure.
 
  You are right, but it would be good if we could move towards a point
  where all files have that directory structure. Otherwise, it will be
  the exception, not the rule, that a downloaded zip file can be used
  for updating. For all normal files, people now are forced to unzip
  to a temp directory and spend time to sort the files to put them in
  the right directories in their installed freedos.

 It's not realistic to assume we will be able to have *every* zip file
 on the ibiblio archive to use the FreeDOS pkg directory structure.
 There are a few problems here:

 1. Not all developers care about FreeDOS pkg structure. And it would
 be inappropriate of me to re-zip their release into a FreeDOS
 pkg-compatible structure. (It would be ok to create a pkg to put on
 the update server, but it is not ok to re-zip someone else's work
 before putting it in the general archive.) Also note that sometimes we
 put zip files on ibiblio that cannot be included on the FreeDOS
 distribution because they are not free for all, but are useful for
 some. The license for these non-free programs may prohibit
 repackaging.

As I see it, the fact that some DOS software is mirrored at ibiblio's
FreeDOS repository is a privilege, not a nice present.
Thus, it could be an idea that there is some kind of FreeDOS logotype
test (LOL ;-)) meaning that some programs have passed the minimum
requirements of:
- An LSM is submitted, so that the software is fully described
- It fully follows the pkg structure.

At certain time I even thought of a second approach to this problem: a
FreeDOS package to be a ZIP file with another extension (say FPF or
FreeDOS Package File) matching certain conditions, such as:
- it follows the pkg structure
- there exists the appinfo/XXX.LSM file
I thought of the second because the programmer could encode in that
LSM the condition to run certain Post-Install script, that would be
run after the package is installed. The extended LSM could host
other information, that we might not exploit at this moment, but maybe
in the future. Things like: dependencies, path to executable, path to
a HTML-Help file (for automatic Help update), etc.
Then there's the decission whether the FreeDOS package would be able
to deal with these special FPF files (and deal with the versioning
stuff, post-install script, maybe dependencies), and for standard ZIP
packages, well, just the basic (there exists XXX.ZIP with date YYY,
newer than current XXX.LSM, install?).

 3. We may (at some later date) choose to change the FreeDOS pkg
 directory layout. As of today, no suggestions to do this have been
 made, but a year from now it's possible that we may want to change it.
 I don't want to re-zip everything on ibiblio to meet the new pkg
 standard.

Perhaps it is the moment to see if the pkg structure needs a review or
not. We could discuss about it, and settle certain FreeDOS directory
structure 1.0, so that programs are based on it.

A clever idea that Microsoft does (for example, to allow locale in
filenames, C:\Program Files is, in my system, C:\Archivos de
Programa\) IIRC is to use a kind of location variable, so that for
example, %10 would be Program Files, %11 would be Windows folder, etc.
It would be certainly quite a lot of more work, but it could be that
the ZIP (or FPF) does NOT have directories, but has instead a mapping
file:
\DISKCOPY.001   =  %12\DISKCOPY.EXE
(and in turn, %12 could be standarised to C:\FREEDOS\BIN by the
packager program).

 4. Others who roll their own distro for themselves or for a distro
 they make available to others may not want to use our pkg directory
 layout, but instead go with something slightly different.

and don't they have their own package program too (as in Linux)?

   But the FDUPDATE program will be downloading these files using
   wget to a DOS filesystem.
 
  Suggestion: wget -O choicex.zip http://foo/bar/choice-4.4-binary.zip
 
  This also makes sure that you have a static name of the
  downloaded file (does not contain a version number) and also
  a readable name (does contain the full name choice) after
  the download and a readable name including a readable version
  number on the server :-).
 
  Remember that it is useful if people can find a package with
  google. Bonnie probably has a lot of experience with this
  when she tried to find new downloads of various packages...
  She would not have found a dkcp0815.zip when looking for
  freedos diskcopy.

 Your suggestion works well when the package title is 7 characters or
 less. But you give an example of a package title that is 8 characters
 (DISKCOPY). Also DISKCOMP, 

Re: [Freedos-user] FreeDOS Updater

2007-12-02 Thread Aitor Santamaría
Hello,

2007/12/2, Eric Auer [EMAIL PROTECTED]:
  put zip files on ibiblio that cannot be included on the FreeDOS
  distribution because they are not free for all...

 You are right. The updater can make use of extra nonfree
 repositories outside ibiblio, while our ISOs gotta be free.

Following the idea I exposed before, you could even have locally a
folder called:

C:\FREEDOS\3RDPARTY\...

where it would unpackage all that is not packaged on the new structure
(in the words before, being a ZIP and not a FPF).

  I don't want to re-zip everything on ibiblio to meet the new pkg
  standard.

 The standard is not new - I only suggest to re-zip everything
 which will be part of FreeDOS 1.1, because there is not other
 choice. You need zips in fdpkg format for every single package
 which will be on the ISO, and we need helpers for that task.

I agree.

 For the beta9 and 1.0 distros, Bernd and Blair had to do most
 of this work themselves, and it is a lot of work because there
 are many packages and because quite a few are not already in
 fdpkg format when you download them from the developer's page.

True. And I even remember that if you made small mistakes about the
pkg structure, they would fix that.

Aitor

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-02 Thread Aitor Santamaría
Hello,

2007/12/2, Jim Hall [EMAIL PROTECTED]:
 There is an important difference. What I put in the general archive on
 ibiblio is a mirror of other people's work. For most programs, they
 already have another primary location, and (license permitting) I'm
 just putting it on ibiblio so that it has at least a 2nd place to live
 (for example, in case the original site goes down or otherwise becomes
 unavailable.) Users should still be able to download the original
 program in its original archive from ibiblio, AND IT SHOULD BE
 IDENTICAL TO WHAT WAS ORIGINALLY RELEASED BY THE AUTHOR/MAINTAINER.

But it is not even true for the packages in the distributions,
compared to the ones created by us (for which I'm grateful, they are
better!).

 Else, it would confuse which was the version that the author had
 actually released. That's why when I reply to announcements about new
 program versions on this list, I consistently say I mirrored your
 release on ibiblio, and why I no longer convert rar files to zip
 files.

 It would also mean the general archive on ibiblio was no longer a
 mirror site - and it needs to remain a mirror site.

May I then suggest the use of the mapping file that I mentioned in the
previous mail?
In fact, the example you mentioned, 4DOS, will probably not have an
LSM launched.

Perhaps it could be a good idea that besides any ZIP (untouched) there
would be a file with the same name, but some extension, like LSM or
another, that would contain all those extra info needed for the
packager: the version or date to compare, the mapping of files onto
the pkg structure, and other useful info (such as post-install script
that I mentioned too). Actually, this info file could be the XML that
Jim suggested, a quite extensible idea (hopefully XMLs are easy to
read in C?).

Thus, a ZIP that does NOT have such file could be extracted asking the
user for a directory, whereas if such info file exists, it is clear
what is to be done.

True that it's some quite extra work to be done (specially for source packages).

 Mateusz  I just had a brief off-list discussion where I suggested we
 may want to change how FDPKG manages packages. One thing we may want
 to do is have all pkg files have a PKG or FDP (FreeDOS Package)
 extension, rather than keep the zip extension, even though the pkg
 file is just a zip file with a particular directory structure.
 Changing the extension would be a good way to implicitly declare that
 the pkg file is not the original release zip file (4dos759.zip 
 4dos759.fdp, for example.)

Oops, I hadn't read this when I wrote my previous mail. Needless to
say, I like the idea ;-)

 It might be a good/interesting idea, though, to add an option to
 FDUPDATE to tell it to read/unzip the packages in-place (i.e. assume a
 local repo) rather than wget them to a local cache. Obviously, that
 works well when the repo is local, but not so well when the repo is on
 a web server somewhere.

You're talking (I guess?) as some type of repository type, that
could be either internet or local. Perhaps the address could give
the clue:
http://www.freedos.org/
file://d:\updates

Aitor

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-01 Thread Mateusz Viste
On Saturday 01 December 2007, Blair Campbell wrote:
 just adding my two cents, but there is already a directory on ibiblio
 with all of the 1.0 packages:
 www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs

Indeed, but some (or even most) of these packages are outdated, and their 
newer releases aren't packaged in the FreeDOS package format yet.

Mateusz Viste

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-01 Thread Mateusz Viste
On Saturday 01 December 2007, Aitor Santamaría wrote:
 (1) About the files to be put, I guess that the package system would
 not, for the moment, try to download from a site outside ibiblio
 itself, so the binary and source files could be simply unix links to
 the actual files in the freedos repository (you can even create them
 with an FTP client).

No, it couldn't, as the newer packages aren't on ibiblio yet (at least not in 
the FreeDOS package format). That's why I am storing all newer packages on my 
website (until Jim do that on freedos.org or ibiblio).

 (2) I think there should be some way of categorising, or at least, the
 user should be prompted. For if I have the mini distribution without
 sources, I wouldn't want everything from the full distribution with
 sources. Actually, is there any different behaviour with new files
 than with updated files?

Of course.
By default, FDUPDATE looks at what you have on your system, and updates these 
packages if newer are available. It _do_not_ install any new package. 
Therefore, categorizing is not needed, as you will get only the packages you 
already have anyway (but in latest versions).
The /new switch of the program (which will be functional in the v0.51), will 
allow you to install new package. For example: You got a 7z file from 
somewhere, but you don't have 7zip installed. No problemo. Just launch the 
FreeDOS Updater (using FDUPDATE /NEW), and it will show all packages which 
are on the server, but not on your local system. Al you would have to do is 
to select 7zip and press enter. Voila!

 (3) I guess that the system does have some local DB to compare to
 the remote DB and see what is to be downloaded. Is this local DB XML
 or LSM?

Yes, it does. In the FreeDOS 1.0 release, all package are listed in 
the %DOSDIR%\PACKAGES directory, and all informations about these packages 
are stored in %DOSDIR%\APPINFO\*.LSM

 Thanks again!

You're welcome ;-)

Mateusz Viste

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-01 Thread Jim Hall
Yup, we're looking to extend that by adding updates to packages in the distro.

Actually, I do not think that FDUPDATE as currently being discussed
could be retrofitted to the FreeDOS 1.0 distro. I think it would need
to go with a FreeDOS 1.1 distro (i.e. the next one) so we could make a
common set of assumptions.

That's why I suggested a /pkgs (installer packages from the 1.1
distro), /updates (update data for later updated packages),
/updates/pkgs (updated packages for each install set) organization
of directories on the file server.

-jh


On 11/30/07, Blair Campbell [EMAIL PROTECTED] wrote:
 just adding my two cents, but there is already a directory on ibiblio
 with all of the 1.0 packages:
 www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs

 On 11/30/07, Florian Xaver [EMAIL PROTECTED] wrote:
  Thank you!! Very good idea! I will download the zip-files now...
 
  Bye
Flo
 
  Mateusz Viste escribió:
   Hello!
  
   I wrote an online updater for FreeDOS. It's purpose is to download an 
   index
   file from the FreeDOS Update server, and compare the list of packages 
   which
   are on the server whith the packages installed on the system. If it find
   any remote package with a different version than the local one, it will
   propose to update it.
   The whole program isn't finished yet (v0.50), but is working fine. It 
   have a
   pre-configured update URL pointing
   to http://mateusz.viste.free.fr/fdupdate;, that's where I am storing the
   newest freedos packages (the url may changes later to something
   more official).
  
   FDUPDATE requires the following packages:
   FDPKG (installed by default with FreeDOS)
   WGETX (may be downloaded at 
   http://mateusz.viste.free.fr/fdupdate/wgetx.zip)
  
   The FreeDOS updater itself may be downloaded from:
   Bin: http://mateusz.viste.free.fr/dos/fdupdatx.zip
   Src: http://mateusz.viste.free.fr/dos/fdupdats.zip
  
   Obviously, you need a packet driver and a working internet connection to 
   use
   FDUPDATE.
  
   Any comments are welcome!
  
   bye,
   Mateusz Viste
  
   -
   SF.Net email is sponsored by: The Future of Linux Business White Paper
   from Novell.  From the desktop to the data center, Linux is going
   mainstream.  Let it simplify your IT future.
   http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
   ___
   Freedos-user mailing list
   Freedos-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/freedos-user
 
  -
  SF.Net email is sponsored by: The Future of Linux Business White Paper
  from Novell.  From the desktop to the data center, Linux is going
  mainstream.  Let it simplify your IT future.
  http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
  ___
  Freedos-user mailing list
  Freedos-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/freedos-user
 


 --
 Fall is my favorite season in Los Angeles, watching the birds change
 color and fall from the trees.
David Letterman (1947 - )

 See ya

 -
 SF.Net email is sponsored by: The Future of Linux Business White Paper
 from Novell.  From the desktop to the data center, Linux is going
 mainstream.  Let it simplify your IT future.
 http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-01 Thread Jim Hall
On 11/30/07, Eric Auer [EMAIL PROTECTED] wrote:

 Hi!

  Why should we put all packages versions on the update server?

 Actually I would not - I would put the package on ibiblio and
 only let the update server know about the ibiblio URL. And as
 more (!) users will update manually than with the updater, it
 is pretty helpful to have ibiblio filenames which do contain
 the full version number and full package name, even though that
 will give many files names longer than 8+3. You can use the
 WGET -O option to set a fixed short output file name for what
 the updater will store on harddisk :-).

I would rather create a system that doesn't specifically rely on
ibiblio as the install source. Yes, it's our primary site. But there
are other mirror archives of the ibiblio files, and for some users in
remote locations it might make more sense to point their FDUPDATE to
one of the mirror sites.

That's why, in my email, I was trying to keep things intentionally
simple. If FDUPDATE knows the site  URI it's downloading from (call
this the repository) then all file references just fall under that.
For example, the FreeDOS 1.1 updates repository might be:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/

That's defined to the FDUPDATE program in some way, probably via an
INI file. So FDUPDATE picks the list files from there, which contain
references to pkg (exe) and spkg (src) files as, say, choic44x.zip
(in pkgs) and choic44s.zip (in spkgs). Assuming we just
downloaded the list file for 'base', it's fairly trivial for FDUPDATE
to glue things together to know to fetch the pkg file from:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/pkgs/base/choic44x.zip

.. and the spkg from:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/spkgs/base/choic44s.zip


In other words, the pkg file from:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/
+ pkgs/
+ base/
+ choic44x.zip

.. and the spkg from:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/
+ spkgs/
+ base/
+ choic44s.zip


One more thing: I think the pkgs and spkgs for the update server
should be assumed to be different than the zip files that we upload to
ibiblio. A pkg and spkg have a particular meaning; they contain a
particular directory structure. The zip files are not always
guaranteed to have that directory structure - an author may simply
have zipped up his/her work directory.


  I would rather put all packages into one directory

 I remember that this made the 1.0 download any package
 from 1.0 directory very user unfriendly. It contains way
 too many files, with way too short names, so many users
 got headaches when trying to download diskcopy of 1.0
 or similar... Plus it did not tell them whether the 1.0
 version or the version in, say, the diskcopy directory
 of ibiblio was newer. I suggest the solution to have all
 versions of diskcopy only in the diskcopy directory, and
 name them diskcopy-0815x.zip or similar instead of
 dkcp815x.zip or dskcpyx.zip or similar ;-).

No, I don't agree with all of that. Yes, we should organize the
packages into a directory structure that makes sense. See my comments
above. But the FDUPDATE program will be downloading these files using
wget to a DOS filesystem. The pkgs and spkgs on the update server
should be named using an 8.3 syntax.

If we name the files on the update server using a non-8.3 syntax, then
that means the FDUPDATE program would need to be modified to download
the files into a systematically-named 8.3 syntax, something that makes
sense for FDUPDATE's local cache of files-to-be-installed. Not saying
that's a problem or a big obstacle, but that's the result of saying
let's name things without following 8.3.

I think we should *not* name all pkgs for all versions of CHOICE as
choicex.zip, and all spkgs as choices.zip. This makes it very
difficult for someone to follow the progress of the versions of CHOICE
that made it into the updates repository. It is important to ensure
that each version may be identified separately. This is especially
important with software covered under the GNU GPL, because the update
server becomes the distribution point.


-jh

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-01 Thread Eric Auer

Hi Jim,

 I would rather create a system that doesn't specifically rely on
 ibiblio as the install source. Yes, it's our primary site. But there
 are other mirror archives of the ibiblio files...

That was part of the point: Ibiblio has high capacity servers
and there are even regional mirrors of it.

 references to pkg (exe) and spkg (src) files as, say, choic44x.zip

People who google for choice will not find it that way...
But it is a good idea that you suggest subdirectories:

 + pkgs/
 + base/
 + choic44x.zip

 One more thing: I think the pkgs and spkgs for the update server
 should be assumed to be different than the zip files that we upload to
 ibiblio. A pkg and spkg have a particular meaning; they contain a
 particular directory structure.

You are right, but it would be good if we could move towards a point
where all files have that directory structure. Otherwise, it will be
the exception, not the rule, that a downloaded zip file can be used
for updating. For all normal files, people now are forced to unzip
to a temp directory and spend time to sort the files to put them in
the right directories in their installed freedos.

 But the FDUPDATE program will be downloading these files using
 wget to a DOS filesystem.

Suggestion: wget -O choicex.zip http://foo/bar/choice-4.4-binary.zip

This also makes sure that you have a static name of the
downloaded file (does not contain a version number) and also
a readable name (does contain the full name choice) after
the download and a readable name including a readable version
number on the server :-).

Remember that it is useful if people can find a package with
google. Bonnie probably has a lot of experience with this
when she tried to find new downloads of various packages...
She would not have found a dkcp0815.zip when looking for
freedos diskcopy.

I hope Mateusz can implement a system where the URL is no
longer required to contain the target 8.3 filename.

Eric



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-12-01 Thread Eli


Mateusz Viste wrote:

Yes, it does. In the FreeDOS 1.0 release, all package are listed in 
the %DOSDIR%\PACKAGES directory, and all informations about these packages 
are stored in %DOSDIR%\APPINFO\*.LSM


I am confused here. I installed FreeDOS 1.0 Full on a 10-year Dell. 
These directories are not on the C: drive. So I looked on the FreeDOS 
1.0 Full CD-R I had burned from a downloaded .iso file. Apparently 
%DOSDIR% has two values*!*

I found a directory \FDOS\appinfo, which has only one file (exe2bin.lsm, 
which looks like what you are talking about in this thread). I found a 
directory \FreeDOS\packages, which has many files, whose names and 
contents remind me of the installation process. (I just went ahead and 
installed everything — space is not an issue.)

Just pointing out that at least some of the distro discs do not match 
the description above.

—Solo Owl





-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater FreeDOS install

2007-12-01 Thread Mateusz Viste
On Saturday 01 December 2007, Eli wrote:
 I found a directory \FDOS\appinfo, which has only one file (exe2bin.lsm,
 which looks like what you are talking about in this thread). I found a
 directory \FreeDOS\packages, which has many files, whose names and
 contents remind me of the installation process. (I just went ahead and
 installed everything — space is not an issue.)

I would say that something gone wrong with your install...

You definetely should not have \FDOS _and_ \FREEDOS directories, but only one 
of these!
Were you installing the 1.0 distro over an existing (older) FreeDOS 
installation?
%DOSDIR% should point to the directory FreeDOS is installed. It can't have two 
values... (don't look at the CD's structure, as it is a bit different, 
because it is tuned for a live-cd work).
Your \FreeDOS\packages directory seems to be okay. \appinfo should be there 
too, and it should have much more files (one file for each installed 
package)!

What are you exactly getting when typing echo %dosdir%?

I installed the 1.0 distro several times, and I always got the directory 
structure I wrote about. I really have no idea what could happen with your 
install :-)
Maybe try to install it again, letting it to keep default parameters?

Mateusz Viste

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-11-30 Thread Aitor Santamaría
Hello,

Congrats on the package system!! I think it is a great idea.

Just some comments:
(1) About the files to be put, I guess that the package system would
not, for the moment, try to download from a site outside ibiblio
itself, so the binary and source files could be simply unix links to
the actual files in the freedos repository (you can even create them
with an FTP client).

(2) I think there should be some way of categorising, or at least, the
user should be prompted. For if I have the mini distribution without
sources, I wouldn't want everything from the full distribution with
sources. Actually, is there any different behaviour with new files
than with updated files?

(3) I guess that the system does have some local DB to compare to
the remote DB and see what is to be downloaded. Is this local DB XML
or LSM?

Thanks again!
Aitor

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-11-30 Thread Florian Xaver
Thank you!! Very good idea! I will download the zip-files now...

Bye
  Flo

Mateusz Viste escribió:
 Hello!
 
 I wrote an online updater for FreeDOS. It's purpose is to download an index 
 file from the FreeDOS Update server, and compare the list of packages which 
 are on the server whith the packages installed on the system. If it find 
 any remote package with a different version than the local one, it will 
 propose to update it.
 The whole program isn't finished yet (v0.50), but is working fine. It have a 
 pre-configured update URL pointing 
 to http://mateusz.viste.free.fr/fdupdate;, that's where I am storing the 
 newest freedos packages (the url may changes later to something 
 more official).
 
 FDUPDATE requires the following packages:
 FDPKG (installed by default with FreeDOS)
 WGETX (may be downloaded at http://mateusz.viste.free.fr/fdupdate/wgetx.zip)
 
 The FreeDOS updater itself may be downloaded from:
 Bin: http://mateusz.viste.free.fr/dos/fdupdatx.zip
 Src: http://mateusz.viste.free.fr/dos/fdupdats.zip
 
 Obviously, you need a packet driver and a working internet connection to use 
 FDUPDATE.
 
 Any comments are welcome!
 
 bye,
 Mateusz Viste
 
 -
 SF.Net email is sponsored by: The Future of Linux Business White Paper
 from Novell.  From the desktop to the data center, Linux is going
 mainstream.  Let it simplify your IT future.
 http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-11-30 Thread hsv
 20071130 10:50 -0600, Jim Hall 
But dates are a problem. Mostly we have been using dates
like 2007-11-26, but there are a few packages out there that use a
different syntax.

I've been thinking about converting the LSM system into a
database-driven system that happens to output in LSM and HTML formats
... so if I do that, 

But isn't year-month-day-hour-minute-second-... HTML format?
If not, what do you mean?


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-11-30 Thread Mateusz Viste
Hi,

As the thread became public, I will just add my offlist $0.02 (pasted from 
offlist mails) ;-)

On Friday 30 November 2007, Jim Hall wrote:
  so if I do that, I could deliver Entered-date (last modified) in
 ctime format, so FDUPDATE always get dates like Wed Nov 21 21:49:08
 2007.

I agree, that would solve the probleme for ever. Not necessarily in the ctime 
format, but at least an format common to all LSM files... But ctime would be 
nice.
The problem is that all users will have to update their whole system the first 
time they launch FDUPDATE, as FDUPDATE will not be able to retrieve ctime 
informations from the local LSM files...

 But how do you know what package file to fetch? For a package named
 foo with version 3.1, the exe package would likely be FOO31X.ZIP
 and the src package would be FOO31S.ZIP. But not everyone uses the
 same version format, so that's a problem. And so you have package
 names that don't easily fit into 8.3, even simple cases like choice
 with version 4.4 ... how do you surmise the correct package name? I
 think I need to pass back a reference to the exe and src package
 names:

Why should we put all packages versions on the update server? An update server 
is meant to have the most up-to-date version. The package's version would 
appear only in the main xml file, but for example the CHOICE v4.4 packages 
would be named CHOICEX.ZIP and CHOICES.ZIP, just like on the install CD.
If a new version of CHOICE appear, all to do is to replace the CHOICEX.ZIP and 
CHOICES.ZIP files, and update the XML content...

 On ibiblio, I could set up an updates subdirectory. So for the
 future FreeDOS 1.1 distribution, we'd have
 http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/u
pdates/

I thought rather of an unique update server... FreeDOS updates haven't any 
version dependencies (like in Linux), if we get, say, a new CHOICEX package, 
all users will be invited to update it - no matter if they are running 
FreeDOS 1.0, FreeDOS beta 9, or anything else.
That way you could set up a server on www.freedos.org/fdupdate, and just add 
packages from time to time. The update URL will remain the same, and if 
anyone get FreeDOS v1.0 in ten years, he will be able to update it easily, as 
the update server will still be in the same place...

 Under updates we could have a separate subdirectory to separate exe
 packages (pkg) from src packages (spkg). For example:

 /distributions/1.1/updates/pkgs/
 /distributions/1.1/updates/spkgs/

The packages may be all in the directory as well, but end up differently 
(ie. CHOICEX and CHOICES)...
The package list on an installed system is stored in one directory too 
(in /freedos/packages)...

 That's not too different from how things are set up in the FreeDOS 1.0
 distribution. And at the updates directory level, I could drop in a
 data file for each disk set, that contains the list of packages for
 that set, using the format described above.

 /distributions/1.0/updates/base.lst
 /distributions/1.0/updates/devel.lst

But... An user may have installed only some packages from devel, and some 
from base, and even others, non-freedos tools (like wget)...
I would rather put all packages into one directory, along with one xml file... 
FDUPDATE will update only those packages which are already installed on the 
user's system anyway...

Bye!
Mateusz Viste

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-11-30 Thread Eric Auer

Hi!

 Why should we put all packages versions on the update server?

Actually I would not - I would put the package on ibiblio and
only let the update server know about the ibiblio URL. And as
more (!) users will update manually than with the updater, it
is pretty helpful to have ibiblio filenames which do contain
the full version number and full package name, even though that
will give many files names longer than 8+3. You can use the
WGET -O option to set a fixed short output file name for what
the updater will store on harddisk :-).

 I thought rather of an unique update server...

Would make it more easy to look at the wrong place and get
the not-newest version, so I think the update server should
be more some place for machine readable version info and
not a place for not human readably named zip files ;-)).

 I would rather put all packages into one directory

I remember that this made the 1.0 download any package
from 1.0 directory very user unfriendly. It contains way
too many files, with way too short names, so many users
got headaches when trying to download diskcopy of 1.0
or similar... Plus it did not tell them whether the 1.0
version or the version in, say, the diskcopy directory
of ibiblio was newer. I suggest the solution to have all
versions of diskcopy only in the diskcopy directory, and
name them diskcopy-0815x.zip or similar instead of
dkcp815x.zip or dskcpyx.zip or similar ;-).

Eric



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-11-30 Thread Jim Hall
On 11/30/07, Mateusz Viste [EMAIL PROTECTED] wrote:
 Hello!

 I wrote an online updater for FreeDOS. It's purpose is to download an index
 file from the FreeDOS Update server, and compare the list of packages which
 are on the server whith the packages installed on the system. If it find
 any remote package with a different version than the local one, it will
 propose to update it.
 The whole program isn't finished yet (v0.50), but is working fine. It have a
 pre-configured update URL pointing
 to http://mateusz.viste.free.fr/fdupdate;, that's where I am storing the
 newest freedos packages (the url may changes later to something
 more official).
 [...]

This project has me very excited about FreeDOS!! This makes it easier
on users who want to stay current on software, even during times when
we haven't released a new version of FreeDOS in a while. I love it!

Mateusz  I have also been working on this off-list. A few thoughts,
to bring the rest of you up to date:


When deciding what packages need updating, the easiest thing would be
to compare the date  version of the installed package vs what's
available on the update server (using an LSM or some other
identifier.) But dates are a problem. Mostly we have been using dates
like 2007-11-26, but there are a few packages out there that use a
different syntax.

I've been thinking about converting the LSM system into a
database-driven system that happens to output in LSM and HTML formats
... so if I do that, I could deliver Entered-date (last modified) in
ctime format, so FDUPDATE always get dates like Wed Nov 21 21:49:08
2007.

There's an additional advantage to displaying Entered-date using ctime
output: sometimes, we may edit an LSM file at two points during the
day (for example, some developers have been known to release two
versions of a program at different times during a single day.) Using
ctime format would include the time, so you not only know the DATE an
entry was updated, but the TIME.

I think FDUPDATE would have a much easier time reading  comparing
that output, too.

I'm really stuck on version numbers, though, since not everyone uses
the same format for how to assign the Version label. For example, I
usually use the simple labels 1.2, 3.1, ... but sometimes 3.1a
if all I've added is a translation file. But some developers often
omits version number altogether, so I fake it when updating the LSM
file by using an encoded date (for example, Version: 21jun2007.)

I suppose one middle ground method to know when to apply a
supposedly-updated package is when the Entered-date is NEWER and the
Version is DIFFERENT from what's installed. I suppose (when in doubt)
you would apply a supposedly-updated package if *both* Entered-date
and Version differ from what's installed. That probably only happens
when there's an update. Probably.

Mateusz and I have been discussing file formats and the update server.
Here are a few thoughts:


For the file format:

I'd really prefer to pass back an XML file. It's easily extensible to
suit many needs here. In the simplest case to identify the package
title, version, and LSM entered-date, we would have:

pkglist
pkginf
 title id=CHOICE /
 version id=4.4 /
 entereddate id=2003-09-20 /
/pkginf
/pkglist

Obviously, there would be multiple pkginf sections, one for each package.

But how do you know what package file to fetch? For a package named
foo with version 3.1, the exe package would likely be FOO31X.ZIP
and the src package would be FOO31S.ZIP. But not everyone uses the
same version format, so that's a problem. And so you have package
names that don't easily fit into 8.3, even simple cases like choice
with version 4.4 ... how do you surmise the correct package name? I
think I need to pass back a reference to the exe and src package
names:

pkglist
pkginf
 title id=CHOICE /
 version id=4.4 /
 entereddate id=2003-09-20 /
 pkg id=choic44x.zip /
 spkg id=choic44s.zip /
/pkginf
/pkglist



For the server:

On ibiblio, I could set up an updates subdirectory. So for the
future FreeDOS 1.1 distribution, we'd have
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/

Under updates we could have a separate subdirectory to separate exe
packages (pkg) from src packages (spkg). For example:

.../distributions/1.1/updates/pkgs/
.../distributions/1.1/updates/spkgs/

That's not too different from how things are set up in the FreeDOS 1.0
distribution. And at the updates directory level, I could drop in a
data file for each disk set, that contains the list of packages for
that set, using the format described above.

.../distributions/1.0/updates/base.lst
.../distributions/1.0/updates/devel.lst

So to do an update, the FDUPDATE program would just fetch
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/updates/base.lst
for the list of what updates to get for the base disk set. FDUPDATE
would crawl through the base.lst file, compare the Entered-date and
Version for each package against 

Re: [Freedos-user] FreeDOS Updater

2007-11-30 Thread Eric Auer

Hi Jim,

to bring my off-list thoughts about the updater on the list:
I agree that using LSMs would be better than using a flat
directory of zips. The version numbers are not machine
comparable, but LSMs are machine readable. As it is highly
unlikely that the update server has an OLDER version than
the user, I think it is enough to update as soon as the
user and the server use a DIFFERENT version number of some
package :-).

Another issue is that LSMs do not yet contain exact file
names for downloads. This is intentional, as giving a
more front page URL allows the user to manually look
if there is an even newer version than the one mentioned
in the LSM already. In addition, many non-core packages
simply have no ZIP with freedos installer / fdpkg compatible
package / directory structure on their homepage, so the
main use of LSM at the moment is helping the user when he
does manual updates of packages.

Of course the update server could have some sort of data
file which has pointers to exact download URLs. Somebody
will also have to make well-structured zips, but as soon
as those are available, I would NOT put them on the update
server. Instead, I would put them on ibiblio, where we
already do keep copies of all packages.

Rugxulo, Fritz and others have provided a big update of the
LSM collection already, so we already know about a big number
of updated packages and where to download them, even though
those downloads are often not in fdpkg compatible shape yet.
Everybody is welcome to help in making nicely shaped zips :-).

Note that if you turned LSM into output of a database, then
it will be harder for you to receive zips with updated LSMs
from people like Fritz.

Using the LSM timestamp / entered-time in addition to the not
really machine readable version numbers is certainly an idea.
I would not want to force everybody to use some unified version
numbering scheme, so using timestamps is a good fallback. Plus,
as said if version numbers DIFFER, then the server probably
has a newer version :-).

 I suppose one middle ground method to know when to apply a
 supposedly-updated package is when the Entered-date is NEWER and the
 Version is DIFFERENT from what's installed. I suppose (when in doubt)
 you would apply a supposedly-updated package if *both* Entered-date
 and Version differ from what's installed. That probably only happens
 when there's an update. Probably.

Agreed. In the latter case, you could prompt the user :-).

 On ibiblio, I could set up an updates subdirectory.

That is a nice idea, but I hope that it will only contain copies
of files which have been updated in their native ibiblio subdirectory
as well before... ;-)

 Under updates we could have a separate subdirectory to separate
 exe packages (pkg) from src packages (spkg). For example:

Good idea. Maybe even separate per category (base, ...).

Eric

PS: LSM files are a classic, but certainly not the best choice
for everything. For example, LSM waste a lot of space on disk
when you install DOS on a filesystem with big clusters, as the
LSMs are small but many files.


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS Updater

2007-11-30 Thread Blair Campbell
just adding my two cents, but there is already a directory on ibiblio
with all of the 1.0 packages:
www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs

On 11/30/07, Florian Xaver [EMAIL PROTECTED] wrote:
 Thank you!! Very good idea! I will download the zip-files now...

 Bye
   Flo

 Mateusz Viste escribió:
  Hello!
 
  I wrote an online updater for FreeDOS. It's purpose is to download an index
  file from the FreeDOS Update server, and compare the list of packages which
  are on the server whith the packages installed on the system. If it find
  any remote package with a different version than the local one, it will
  propose to update it.
  The whole program isn't finished yet (v0.50), but is working fine. It have a
  pre-configured update URL pointing
  to http://mateusz.viste.free.fr/fdupdate;, that's where I am storing the
  newest freedos packages (the url may changes later to something
  more official).
 
  FDUPDATE requires the following packages:
  FDPKG (installed by default with FreeDOS)
  WGETX (may be downloaded at http://mateusz.viste.free.fr/fdupdate/wgetx.zip)
 
  The FreeDOS updater itself may be downloaded from:
  Bin: http://mateusz.viste.free.fr/dos/fdupdatx.zip
  Src: http://mateusz.viste.free.fr/dos/fdupdats.zip
 
  Obviously, you need a packet driver and a working internet connection to use
  FDUPDATE.
 
  Any comments are welcome!
 
  bye,
  Mateusz Viste
 
  -
  SF.Net email is sponsored by: The Future of Linux Business White Paper
  from Novell.  From the desktop to the data center, Linux is going
  mainstream.  Let it simplify your IT future.
  http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
  ___
  Freedos-user mailing list
  Freedos-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/freedos-user

 -
 SF.Net email is sponsored by: The Future of Linux Business White Paper
 from Novell.  From the desktop to the data center, Linux is going
 mainstream.  Let it simplify your IT future.
 http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



-- 
Fall is my favorite season in Los Angeles, watching the birds change
color and fall from the trees.
   David Letterman (1947 - )

See ya

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user