tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CONFLICTS variable is terrible
>> > How to decide before I waste time downloading a package and its many
>> > dependencies and begin extracting / installing all of them to later find
>> > somewhere in that process that there is a conflict?
>> AFAIU +CONTENTS file is at the very beginning of tarball.
>> So, this checks may be done as soon as downloading starts.
> But why do keep on thinking that information about conflicts is only
> valuable when installing a package?
Ok. I see the following variants.
A) Do not provide the information about conflicts at all.
B) Keep CONFLICTS somewhere
B1) pkgsrc source tree
a) Set CONFLICTS variable inside Makefile manually (Now we are here).
Pros: Individual package's conflicts can easily be seen
just by running bmake.
Cons: Manual maintainance of CONFLICTS is unreliable.
Lots of manual work.
b) Generate CONFLICTS automatically by analysing an entire pkgsrc source tree
using, e.g. pkg_src_summary and pkg_all_conflicts tools.
(emacs vs. xemacs modules in my another email)
Pros: Reliable.
Automatic.
Cons: Individual package's conflicts cannot be seen without analysing
an entire pkgsrc tree. This may take some time...
(See pkg_update_src_summary program,
this is again wip/pkg_summary-utils)
B2) binary pkgsrc repository
a) pkgsrc repository is a collection of binary packages and nothing else.
You MUST keep CONFLICTS variable inside binary in this case.
If it is not set in Makefile,
you should to somehow postprocess binaries after bulk bulds.
Again pkg_all_conflicts and pkg_info -X can used here.
b) pkgsrc repository is a collection of binary packages + pkg_summary(5)
It is trivial to automatically generate information about packages'
conflicts. pkg_all_conflicts is compatible with pkg_summary(5)
(By design. All programs from wip/pkg_summary-utils
are compatible with pkg_summary(5). This were the goal)
======================================================================
A) This is probably inacceptable.
B1a) I personally don't need 'make show-var VARNAME=CONFLICTS'
Do you? On the other hand, maintaining CONFLICTS variable
can be drammatically improved using my latest tools.
B1b) No comments here. See pkg_summary-utils(7)
Almost everything is already implemented for this.
B2a) To me this looks very ugly.
B2b) To me this good enough.
Everything is already implemented for this variant.
Provided that automatic checking will be used in the future at least
before quarter branches, I'm not against B1a.
The same for package's version that should not decrease between releases.
Per quarter release checks may be good enough for the beginning.
Everything, except... is already implemented for this too.
--
Best regards, Aleksey Cheusov.
Home |
Main Index |
Thread Index |
Old Index