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 > 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 :-). 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 and (src) http://..../1.1/updates/spkgs/util/4dos.zip. Packages should be named (exe) http://..../1.1/updates/pkgs/util/4dos759.zip and (src) http://..../1.1/updates/spkgs/util/4dos759.zip ... and (exe) http://..../1.1/updates/pkgs/util/4dos758.zip and (src) http://..../1.1/updates/spkgs/util/4dos758.zip. In one of my other emails, I suggested the data file on the update server would need to indicate the pkg and spkg. See below. That's easy to do on the update server, and a good solution. Why do you not think this is a good idea? > > 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. Not sure I understand this. Why would you use FDUPDATE to fetch updates, but then decide to not have FDUPDATE install them so you could install them yourself using 'unzip'? That doesn't make any sense to me. The whole point here is to have an easy, automated way to keep your system up to date. If you don't want to use the automated tool and would rather look at the repository on the update server to download & install manually: FINE, DO THAT. My suggestion didn't say that the files on the update server should be named using non-recognizeable filenames. 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.) > 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 typically install network drivers > after they have installed DOS and worked with it for a while, > instead of throwing in a driver CD during the install process > or having a big collection of drivers on the distro CD already. > The latter is not possible for FreeDOS because licenses of DOS > network drivers often do not let us include drivers on the CD. 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. So let's assume 8.3 here: In other emails, I made a suggestion for how the data file on the update server could indicate which filename had the latest pkg (exe) and spkg (src) update for, say, CHOICE 4.4: >>>>>>>>>>>> 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> <<<<<<<<<<<< and: >>>>>>>>>>>> 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 <<<<<<<<<<<< Now let's put it together. 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 (say, D:/1.1/updates/) and FDUPDATE would happily be able to read the data file that indicated package names & versions & filenames, and would then update all the packages on my system that needed updating. It would know where the correct pkg (exe) file was located by using the "pkg" directive, and would know where to find the spkg (src) file by using the "spkg" directive. In other words, the pkg file from: D:/1.1/updates/ + pkgs/ + base/ + choic44x.zip .. and the spkg from: D:/1.1/updates/ + spkgs/ + base/ + choic44s.zip What changed? Only the repo location. Everything else stays the same. As mentioned above, this assumes everything is 8.3. 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. -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
