On Thursday 16 April 2009 10:13 (CEST), Blair Campbell wrote: > Actually IIRC kitten searches more than just %NLSPATH%\name.lang... > yes... from the source... %NLSPATH%\%LANG%\cat, then > %NLSPATH%\cat.%LANG%. So cats and kitten are probably good, dunno > about foxcubs.
Oh, yeah - you're right :) Foxcubs is doing that, too. Anyway, I don't know if dropping NLS files at the unpacking level is a good (easy) way to go. As said previously, NLS aren't that big, so these few KiB could be easily removed after the install process (DEL *.EN, DEL *.FR, etc). Anyway - I think it's up to the installer's maintainer to decide what's easier for him. :-) Best regards, Mateusz > >> 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
