On Thursday 16 April 2009 04:50 (CEST), Aitor Santamaría wrote: > I strongly suggest to look for a way to exclude with unzip the > extracting of the sources on a binary-only install mode.
You are absolutely right - this is a *must have* for the 1.1 installer! > Just another small pro: we have one more letter in the file names (for > those of us who care about the 8.3 format in the package names). Indeed. Currently, LBACACHE is transformed into LBACACHX. But what if one day we would have both a LBACACHE program, and a LBACACH one? See, crappy things may happen ;-) Having one global package per program is just so much simpler. > And just another idea (maybe for the wiki too, if everyone likes it): > if such option exists in unzip, then I suggest for all programs using > cats/kitten to store their catalog in a per-language basis, so that > the installer can simply drop the directories of the unwanted No way... It would mean rewritting CATS/Kitten/Foxcubs for any existing application, for a really not so great profit... NLS files aren't that big anyway (few KiB...), and it's a great functionality to be able to switch from one language to another just by typing SET LANG=xx. :-) Best regards, Mateusz Viste > 2009/4/9 Eric Auer <e.a...@jpberlin.de>: > > > > Hi Jim :-)) > > > >> On Sat, Apr 4, 2009 at 9:30 AM, Mateusz Viste wrote: > >>> Hi people! > >>> > >>> So far, we have always used packaging sources and binaries differently > >>> (that is, in separate packages, like memx.zip and mems.zip). I am trying > >>> to put some effort these days into syncing some packages to make them > >>> ready for v1.1, and I have to tell that handling sources and binaries in > >>> different ways is a big pain. > >>> Besides that, the "source" package doesn't contain its own LSM file, > >>> which makes its hard (or at least unreliable) to keep track of what > >>> source is installed in what version. > >>> > >>> Therefore, I am proposing to drop the "sources / binaries" way of > >>> thinking, and stay with one package per program. For example, a "mem.zip" > >>> package would contain both sources and binaries. It would allow me to > >>> work much faster on packaging, and hopefully could lead to a v1.1 sooner. > >>> > >>> Some reasons to do that (quotes from Eric): > >>> - it is easy to delete /source/mem/* to keep only binaries, > >>> - it is not really allowed with GNU GPL License to publish binaries > >>> without sources anyway, > >>> - it can be hard for people to find exactly the right version of the > >>> sources manually later, so it is best to include them, > >>> - it makes life easier for installing and you can always drop the sources > >>> after installing. > >>> > >>> Please tell me what are your opinions in that matter. > > > > Jim Hall wrote: > >> These days, hard drives have lots of capacity. While including the > >> sources would add to the size, we're talking on the order of MB, not > >> GB. > >> > >> Including the source and binaries together certainly provides that > >> every program in the "FreeDOS 1.1" distro also includes the source > >> code. > >> > >> I am a big fan of this. > > > > Thanks :-) I think it will make packaging easier... On the other > > hand, I would suggest two things: A binary-only install mode in > > FDPKG / FDUPDATE / installer which simply skips the source/NAME > > dir while unzipping (or deletes it afterwards) and a binary-only > > ISO for people with slow internet, as generated by dropping the > > source directories inside the package zip files. In short: Let > > us COLLECT all packages as FULL packages (binary AND source) for > > most purposes and use AUTOMATED ways to "shrink full into binary" > > for people with small disk or small internet :-). > > > >> Can you put this in the FreeDOS Wiki, so people don't have to revisit > >> this topic again in a year after we've forgotten? :-) > > > > Sounds useful - if anybody needs a wiki login, let me know ;-) > > > > Eric -- You'll find my public OpenPGP key at http://www.viste-family.net/mateusz/pub_key
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
