Hi Paul
Probably the reason this hasn't gotten any discussion is that I don't
see this as a "problem" that needs to be solved.
>From your other email, you said this as a sort of "preamble" to your idea:
>>I believe, source code is for programmers.
>>I believe, executable code is for users.
>>
>>I believe a intermediary between the two should exist.
>>I guess it is a package.
>>I believe this intermediary is for installer(s).
>>I believe this intermediary should be PGP signed.
>>What should it looks like?
Some context and history will probably help here.
A "package" is really just a collection of files - usually software. A
"package" may also have metadata associated with it - usually embedded
in the package file itself.
Linux "packages" differ depending on your Linux distribution, but are
often DEB (Debian & Ubuntu) or RPM (Fedora & RHEL & openSUSE). I'm
more familiar with RPM, and I know there is a separate Source RPM
("SRPM") that contains the source code for that package.
And on Linux, you have different package managers to install and
uninstall those packages.
On any DOS system, the standard (de facto) "package" to distribute
software is ZIP files. (Some people may use RAR files - and going back
a very long way, some packages used to be in ZOO files.) For a long
time, the most popular programs to manage ZIP files was PKWare's PKZIP
& PKUNZIP. These days, it's InfoZip's ZIP & UNZIP.
As a result, we chose ZIP as the default FreeDOS package format. We
provide a few options for package managers such as FDIMPLES or FDNPKG.
These are basically programs that use UNZIP to extract ("install")
these packages, but have other features such as the ability to
traverse a file tree and select packages to install (FDIMPLES) or
install packages from a network (FDNPKG). But if you have the package,
you can just as easily use UNZIP yourself to install it.
The metadata for the package is included in a separate file. The file
format is LSM3, a version of the Linux Software Map descriptor format.
The reason for LSM is historical, but has been the default for so long
it's effectively our standard descriptor format.
We use specific paths in the FreeDOS packages (ZIP files) to make sure
things are installed in the correct locations. The install target is
usually "C:\FDOS". Executable programs ("binaries") are usually in BIN
(so they get installed to C:\FDOS\BIN) and other files get installed
to other standard directories. (A few packages that require a specific
structure get installed elsewhere - these are exceptions.) The package
structure is described on the wiki at
http://wiki.freedos.org/wiki/index.php/Package
In FreeDOS 1.1, we use a single package file that includes both the
executable parts and the program's source code. This makes it really
easy to make sure we include the source code for every FreeDOS
program. Because many FreeDOS programs are distributed under the GNU
GPL, we need to ensure that users can always access the source code.
The GNU GPL v2 says:
> 3. You may copy and distribute the Program (or a work based on it,
>under Section 2) in object code or executable form under the terms of
>Sections 1 and 2 above provided that you also do one of the following:
>
> a) Accompany it with the complete corresponding machine-readable
> source code, which must be distributed under the terms of Sections
> 1 and 2 above on a medium customarily used for software interchange; or,
>
> b) Accompany it with a written offer, valid for at least three
> years, to give any third party, for a charge no more than your
> cost of physically performing source distribution, a complete
> machine-readable copy of the corresponding source code, to be
> distributed under the terms of Sections 1 and 2 above on a medium
> customarily used for software interchange; or,
>
> c) Accompany it with the information you received as to the offer
> to distribute corresponding source code. (This alternative is
> allowed only for noncommercial distribution and only if you
> received the program in object code or executable form with such
> an offer, in accord with Subsection b above.)
By including the source code in the ZIP file, you don't have to locate
and download the associated "Source ZIP" (see "Source RPM" above) if
you want the source code for a program. You just select one of the
"with sources" options when you install FreeDOS. If you don't want the
source code when you install FreeDOS, you select one of the other
options.
Or if you prefer to install a package manually - without the installer
or FDIMPLES, you can use UNZIP to extract (install) the ZIP file
(package). This gives you the executable parts plus the source code.
Or you can the "-x" option to UNZIP to exclude ("-x") the SOURCE
directory.
Jim
On Thu, Jul 25, 2019 at 10:56 PM Paul Dufresne via Freedos-devel
<freedos-devel@lists.sourceforge.net> wrote:
>
> This is clearly work in progress.
> Publishing for comments, even if rather incomplete.
>
> I am realizing I am ignoring the project current package format(s).
> I have the feeling the package format for 1.3 is not documented yet.
> Although one could look at it inside the iso image.
>
> I believe we have to decide which languages we "support", and for each
> language, what encodings we use.
> I believe we should "support" more languages for the CORE packages, than the
> others.
> I guess there is some "mandatory" languages, and some "recommended" languages.
>
> Well, in an ideal world, one would ask to build binary packages from a source
> package,
> and would have nothing to add more.
> But there is quite a lot of information, that the builder must give, not the
> author of source code.
>
> So, what a source package should looks like?
>
> name directory (it is unclear for now, how the info is separated in different
> files)
> author_name
> author_email
> primary url
> secondary url
> common source files
> source license
> documentation license
> BINARIES
> for each binary:
> specific source files
> version
> name
> descr[language]_present: no need to say true, the fact that the line is
> present is telling true
> LANGUAGES
> for each language: (all files is in the encoding chosen by the
> FreeDOS project for this language)
> description.txt
> name.txt (how to use name binary)
> help.txt (shown by the command itself)
> usage.txt (short for name.txt, possibly shown by the command with
> -? option)
>
> Seems to me that if there is just one binary associated with source, then
> common source files should be empty,
> meaning all sources should be in the specific binary directory under BINARIES.
>
> Reading a bit more about pgp, I realized pgp promote detach signatures as a
> way
> to sign a file in a different file (very usefull for binary files).
> They tend to sign a file named name.ext into a file named name.ext.sig
>
> I have updated this idea in this new version.
>
> name.hdr.sig
> name.hdr
> variant: dufresnep
> version: 1.0
> program_name
> program_version
> builder_name
> build_date
> build_hour
> build_compiler_used
> type_of_public_builder_source: none,git,included
> optional git_url
> included_src_type: none, zip, etc.
> author
> type_of_public_source: none, get, etc.
> optional git_url
> descr_present: true/false
> if descr_present then descr_encoding
> llvm_present: true/false
> 32b_present: true/false
> 16b_present: true/false
> src_present: true/false
> if src_present then src_encoding:
>
> name.dsc
>
> optional name.lvm (llvm code)
> if name.lvm is present, then name.lvm.sig should be present
>
> optional name.32b (32 bit code)
> if name.32b is present, then name.32b.sig should be present
>
> optional name.16b
> if name.16b is present, then name.16b.sig should be present
>
> optional name.src
> if name.src is present, then name.src.sig should be present
>
>
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
