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

Re: Using "Priority: optional" in Debian GIS packages

Hi Bas,

On Fri, Nov 22, 2013 at 03:29:49PM +0100, Sebastiaan Couwenberg wrote:
> Not yet. It's a very early work-in-progress. I'll post a link to my git
> repo once it's fully adjusted for Debian GIS, or just push a policy
> branch to the pkg-grass website git repo. The current status is just
> tidying up the XML syntax and replacing Debian Med

Great!  Any XML patch also for Debian Med policy is welcome.  Hint: I
just made some slight changes regarding the usage of Config::Model and
cononical Vcs URLs.

> with Debian GIS. I've
> also forked the pkg-perl website and adjusted it for Debian GIS that
> could serve as a new project page on Alioth instead of redirecting to
> the wiki.


> > IMHO this is an expression of an unnecessary understatement.  The Debian
> > archive is full of packages which are not for everybody.  Perhaps we
> > might file a bug against policy for a better clarification.  I do not
> > think that there is any practical case where a user says:  Please
> > install all packages "priority: optional".  That's not how installation
> > of systems work these days (it might have been in 1996 when I have set
> > up my first Debian box).
> My argument against priority optional was not meant as a blocker,
> because I agree that it's a good idea in general. I do think that the
> current wording in policy doesn't encourage to use priority optional
> over extra in the case of Debian GIS packages. The "should" requirement
> of not conflicting with other optional packages is bit discouraging, but
> can be worked around by using Breaks/Replaces instead of Conflicts if
> the conflict wording is to be taken literally. I also think that policy
> should be updated to reflect the changed usage of Priority values, so
> filing a bug against policy is a good idea.

Even if I agree and brought this up I admit I'm a bit lazy to go forward
with filing the bug ...

> >> I think it's a good idea to at least use "Priority: optional" for the
> >> library packages to allow "Priority: extra" packages to depend on them
> >> without violating policy.
> What I meant to write here is to allow other priority optional packages
> to depend on them. Libraries with priority extra could already be
> depended upon by other priority extra packages, while priority optional
> packages couldn't without violating policy.


> > in optional.  But since this discussion started over a library anyway
> > please change it to optional and we can move on with the discussion
> > while the package is in the queue.
> As you've probably seen in the VCS activity, I've changed the priority
> for the packages I'm involved with so far.

Yep.  Seen and uploaded.  I personally would have probably waitet until
other needed changes might have piled up ... but since you have putted
it on SoB I just did the sponsering. ;-)

> The proj package needs some attention, it's currently priority extra and
> is a dependency of many GIS packages. To not violate policy with its
> rdepends it should be changed to priority optional before GDAL and
> friends. Version 4.7.0 is in the archive, and 4.8.0 is in git thanks to
> Jerome Villeneuve Larouche.

If you ask me some "temporary" policy violation (in terms of fixing a
package in VCS and do not an immediate upload) would be fine.  To the
best of my knowledge there is no real check which is able to verify this
policy requirement and I see no dangerous way to affect the user
experience if we manage to upload right in time before Jessie will be
frozen.  (The priority is relevant for sorting packages into
installation media.)
> Unless someone beats me to it, I'll look into updating PROJ.4 in Debian
> after the SpatiaLite transition is done.


Kind regards



Reply to: