package information are too restrictive

[X512]

Currentrly a lot of fields in ".PackageInfo" are required to fill. But not of them are necessary. "requires" section is not necessary because some packages don't have depedencies at all. For example dictionary data, icon set and others. When building private packages description and license fields can be omitted.

Such fields as package name, description and summary should be localizable.

Also I found strange restriction that space characters in package name is prohibited. This should be fixed to. Many application packages have long name with spaces. I didn't check non-ASCII characters in packafe name, but it should be supported too. Some programs don't have english name at all.

[bonefish]

The "requires" attribute is not mandatory; it can already be omitted. Package description and license are intentionally mandatory, since we'd like to avoid packages that no one knows what they are about and in which way one is allowed to use them. If you're building a package just for yourself, you can just specify dummy values for these attributes.

The package name is intentionally restricted. It is also encoded in the package file name, so white space and non-ASCII characters would be annoying. Maybe we should introduce a "display name" attribute.

Description and summary should indeed be localizable. We haven't worked out how we'll handle that. The translations will very likely not end up in the package file itself or in the package info, since that would just add unnecessarily to the package size. We'll most likely implement that at the repository level.

[X512]

Replying to bonefish:

Package description and license are intentionally mandatory, since we'd like to avoid packages that no one knows what they are about and in which way one is allowed to use them. If you're building a package just for yourself, you can just specify dummy values for these attributes.

Summary field is probably enougth, there are no need to force write long description. License sometimes is unknown and can't be provided (for example author of program didn't mentioned licence). Also not all licenses are called or called generally such as "EULA". Will this introduce name conflict or not?

The package name is intentionally restricted. It is also encoded in the package file name, so white space and non-ASCII characters would be annoying. Maybe we should introduce a "display name" attribute.

Why file name should be dublicated inside a package itself? Also spaces and Unicode characters are OK in filenames (excluding FAT12 and other ancient filesystems).

Personally I'm strictly against "computer" file names and always call files with natural names.

Description and summary should indeed be localizable. We haven't worked out how we'll handle that. The translations will very likely not end up in the package file itself or in the package info, since that would just add unnecessarily to the package size. We'll most likely implement that at the repository level.

Packages musn't be stored in a repository. For example it can be provided by some commertical corporation with special distribufion conditions.

Why not localize PackageInfo itself? for example by edding ":<language id>" to the end of each localizable field?

For example:

name = Haiku
description:en = "Haiku is a new open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful."
description:jp = "Haiku はパーソナル・コンピューティング向け、新しいオペレーティングシステムです。......"
...

At least package name should be localizable for listing installed packages. Other fields can be localized in repository (or moved completly in repository because this information ia already presented in readme, documentation etc.; user will probably read package description only in repository). Only application names should be localized, library package names are not localized.

[bonefish]

Replying to X512:

Replying to bonefish: Summary field is probably enougth, there are no need to force write long description.

Of course the developer and the packager always know what the package is about. Our focus here is on user friendliness. The summary attribute only contains a very short (single line) description which will only very rarely be sufficient to convey all the relevant information. After reading the description the user should know what the package is about and why they may or may not want to install it. If, as a packager, you really can't come up with more useful information than the summary already provides, just copy and paste it to the description and make it a proper sentence. That really isn't a lot of work and only to be done once when initially writing a package info.

License sometimes is unknown and can't be provided (for example author of program didn't mentioned licence).

When no kind of license or terms of use is given, then, by default, you are not allowed to use the software.

Also not all licenses are called or called generally such as "EULA". Will this introduce name conflict or not?

Yes, there would be a conflict. When packaging a software with a custom license the usual approach is to name the license file like the software. E.g. have a look at "/boot/common/data/licenses" for examples.

Why file name should be dublicated inside a package itself? Also spaces and Unicode characters are OK in filenames (excluding FAT12 and other ancient filesystems).

Personally I'm strictly against "computer" file names and always call files with natural names.

The package file name isn't something a user usually comes in contact with. It isn't meant for user friendly reading. Instead it encodes important information like the package version and architecture. Package files may also be stored on systems other than Haiku and may be transferred via various protocols. Sticking to ASCII characters without whitespace avoids potential character encoding and quoting/escaping issues.

Packages can be not stored in a repository. For example it can be provided by some commertical corporation with special distribufion conditions.

I don't know what distribution conditions you're thinking of. Generally it might be interesting even for a commercial company to provide a repository, so that bug fix updates can be delivered automatically to the user. If, for some reason, they want to provide only the package file itself, they could build one per target language with the respectively translated meta information.

As written before, we haven't really worked out how exactly we want to handle localization. We may also provide some way to build all translations into a package.

Why not localize PackageInfo itself? for example by edding ":<language id>" to the end of each localizable field?

That would require the package info file to be changed and the package to be rebuilt whenever a translation is added or a typo is fixed in any of them. I think generally we should keep the translations separate from the package.

[X512]

Replying to bonefish:

The package file name isn't something a user usually comes in contact with. It isn't meant for user friendly reading. Instead it encodes important information like the package version and architecture. Package files may also be stored on systems other than Haiku and may be transferred via various protocols. Sticking to ASCII characters without whitespace avoids potential character encoding and quoting/escaping issues.

But why it should limit package name (not file name) itself? Also why package name should be same as in file name?

I don't know what distribution conditions you're thinking of. Generally it might be interesting even for a commercial company to provide a repository, so that bug fix updates can be delivered automatically to the user. If, for some reason, they want to provide only the package file itself, they could build one per target language with the respectively translated meta information.

Commertical software is usually not free to download (but downloadable software with activation exists, shareware for example). Package can be transfered to the user only after being paid by some sequre method or even by physical media such as CD-ROM. Mayble this is obsolete information because I don't buy software often and prefer free software.

As written before, we haven't really worked out how exactly we want to handle localization. We may also provide some way to build all translations into a package.

Anyway this should be made before package manamement became part of Haiku release officially.

That would require the package info file to be changed and the package to be rebuilt whenever a translation is added or a typo is fixed in any of them. I think generally we should keep the translations separate from the package.

Package names should be translated for listing installed packages as I mentioned before.

[bonefish]

Replying to X512:

But why it should limit package name (not file name) itself? Also why package name should be same as in file name?

The package name is encoded in the file name. IIRC there's even code that needs to infer the file name from the package info. Moreover the package name can also be used in requires and provides declarations. Allowing characters that not everyone knows how to input is rather annoying. If a translatable name is desired, a separate attribute would be better.

[X512]

Replying to bonefish:

Replying to X512:

But why it should limit package name (not file name) itself? Also why package name should be same as in file name?

The package name is encoded in the file name. IIRC there's even code that needs to infer the file name from the package info. Moreover the package name can also be used in requires and provides declarations. Allowing characters that not everyone knows how to input is rather annoying. If a translatable name is desired, a separate attribute would be better.

Entries in "provides" field can be differ from package name, can't they?

[bonefish]

Replying to X512:

Entries in "provides" field can be differ from package name, can't they?

The items in provides can have any name (ASCII with some restrictions). By convention a package has a provides item with the package name.

[pulkomandy]

I think the extra layer provided by HaikuDepot covers this reasonably well.