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
