tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg_summary(5) and license restrictions



> : Unfortunately a few important fields are absent in pkg_summary(5):
> :  NO_BIN_ON_CDROM
> :  NO_BIN_ON_FTP

> : All they are important to make a decision whether to put binaries to
> : ftp:// of cdrom or not.

> : Question 1)
> : What do think about inclusion of these two variable values to
> : pkg_summary(5)?

>   Yes, that sounds reasonable.  I'll add them.

Thanks.

> : Question 2)
> : Is it possible to add/remove some variables to/from pkg_summary
> : generated by 'pkg_info -X'?

>   No, and I don't think it would be a good idea.
[...]
>   (Arguably, including extra variables from BUILD_INFO should be
> relatively unproblematic.  However, any tool that requires them would
> be unable to work with official binary package repositories.)
I understand this and I'm not about binary repositories. But adding
new fields (variable/value pair) may be used by "third party"
applications.

One example - my wip/distbb.  As a result it generates pkg_summary(5)
file that describes every binary package that is in the repository.
As I already said ideally (in my view) this information should be
enough for making a decision whether to put binaries to ftp/cdrom. For
this to work I'd prefer to add two new fields NO_BIN_ON_CDROM and
NO_BIN_ON_FTP to the pkg_summary(5). Then based ONLY on this
information distbb can upload only "valid" binaries. In this case no
additional code is needed - everything is small and workable. Now
suppose that EVERYBODY is against my proposal and there is no way to
EASILY obtain NO_* variables.  In this case additional code around -Bq
or -Q should be implemented - I can do this but I don't think it is
right way... -Bq is not a superset of -X.

Another examples is (again) my pkg_online. One of its functionality is
to show FULL information about particular package - either source or
binary. The word FULL may mean everything - from almost nothing (only
PKGNAME, for example) to exactly those fields mentioned in
pkg_summary(5) and to full information from BUILD_INFO + COMMENT + ...

It is easy to other examples.

This additional flexibility doesn't break anything and costs a few
dozens of lines of source code.

-- 
Best regards, Aleksey Cheusov.


Home | Main Index | Thread Index | Old Index