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 does NOT imply that the URL did use a short file name!), walk to PC 2, which has no modem and no network card, boots DOS, does chdir %dosdir%, does unzip a:some.zip and is happy :-). Without having to move around files after unzipping. I think we actually agree about many things here already, there are just some misunderstandings about details and motivations :-). > <title id="CHOICE" /> > <version id="4.4" /> > <entereddate id="2003-09-20" /> > <pkg id="choic44x.zip" /> Of course this is fine for automated updates. It just is not for google. Google users are more happy with choice-44-binary.zip :-). You can say: <pkg id="choice-44-binary.zip" /> (and save as pkgs/%title%.zip in the updater work directory :-)) > 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. 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