svn commit: r361646 - in head/net/samba36: . files

[Michael Gmelin]

On Wed, 16 Jul 2014 13:12:43 +0100
Vsevolod Stakhov <vsevolod at FreeBSD.org> wrote:

> On 16/07/14 13:07, Alexey Dokuchaev wrote:
> > On Wed, Jul 16, 2014 at 12:58:01PM +0100, Vsevolod Stakhov wrote:
> >> Again, I have no objections about licenses/comments/whatever. I
> >> want actually merely to figure out, which manifest's fields are
> >> *significant*. At this point, I can easily change this list without
> >> insulting users. On the contrary, after 1.3 release that would be
> >> hard.
> > 
> > Understood; sounds certainly reasonable.
> > 
> >> I suggest thus to stop bikescheding and switch to constructive
> >> discussion and define how should we distinguish one package from
> >> another. And no, we *cannot* rely on port version/revision/epoch
> >> only!
> > 
> > One thing that comes to mind is svn info /usr/ports/foo/bar | grep
> > Last Changed Rev.  Then port (portupgrade) users won't get upset by
> > countless portrevs, and pkg will be able to rebuild (redistribute)
> > a package even if maintainer forgot to bump portrev (esp. for an
> > important update).
> 
> Then we would have different packages with the same version. And pkg
> will not perform an upgrade. Nontheless, in the current scheme, we
> take unnecessary fields, such as licenses or comments, into
> consideration. Moreover, manifest cannot rely on svn, so if you take
> a look on some manifest generated from a port you could figure out
> what fields are likely important and what fields are just
> meaningless. I'd like to remind that my current set is the following:
> 
> *  name
> *  origin
> *  version
> *  arch
> *  options

I would remove these:

> *  maintainer
> *  www
> *  message
> *  comment

Rational: If any of those changes and it's important, the maintainer
will bump the revision anyway. None of these have any impact on how the
pkg works in practice, so a loppy maintainer won't harm the user here.

It might be worthwhile to include the following fields instead:

* users
* groups

Since those clearly might make a difference.

Not certain about license related fields.

> 
> And I think it is far from being perfect.
> 



-- 
Michael Gmelin