Re: [Freedos-user] FreeDOS Updater v0.52
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
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
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
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
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
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
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
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
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
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
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
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
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
[...] 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
