[GRASS-dev] osgeo4w package for GRASS 7

GRASS GIS GRASS GIS developer
1

Hi,

in the light of GRASS 7.0.0 release I would suggest to change current
OSGeo4W package naming convention from:

(option a)

* grass70 to grass7 (version 7.0.0)
* grass70-dev to grass7-dev (version 7.0.1svn)
* grass71-dev to grass-trunk-dev (7.1.svn)

or

(option b)

* grass70 to grass (version 7.0.0)
* grass to grass6 (version 6.4.4)
* grass64-dev to grass6-dev (version 6.4.5svn)
* grass70-dev to grass-dev (version 7.0.1svn)
* grass71-dev to grass-trunk-dev (7.1.svn)

It's hot topic, I would like to solve it during this weekend (before
announcing GRASS 7 officially).

Personally I would vote for b). Any opinion? It's strategic decision,
so please feel free to give me feedback ASAP...

Thanks, Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

2

Hi,

[back to the ML]

2015-02-21 14:01 GMT+01:00 Yann Chemin <ychemin@gmail.com>:

Regardless of all the rest, I like the idea of moving grass70 -> grass and grass -> grass6, I feel it kinda makes a statement here, beyond the actual release, it is just the new state of the software.

But then that means simply +1 for option b)

well, b) is probably too much radical from user POV. Moreover in the
most of Linux distributions the name of GRASS 7 package will be
probably `grass7` and not `grass`.

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

3

Martin Landa wrote

Hi,

in the light of GRASS 7.0.0 release I would suggest to change current
OSGeo4W package naming convention from:

(option a)

* grass70 to grass7 (version 7.0.0)
* grass70-dev to grass7-dev (version 7.0.1svn)
* grass71-dev to grass-trunk-dev (7.1.svn)

or

(option b)

* grass70 to grass (version 7.0.0)
* grass to grass6 (version 6.4.4)
* grass64-dev to grass6-dev (version 6.4.5svn)
* grass70-dev to grass-dev (version 7.0.1svn)
* grass71-dev to grass-trunk-dev (7.1.svn)

It's hot topic, I would like to solve it during this weekend (before
announcing GRASS 7 officially).

Personally I would vote for b). Any opinion? It's strategic decision,
so please feel free to give me feedback ASAP...

I tend to b), as we may retire the grass6x-lines with grass7.0.1. thus only
grass, grass-dev and grass-trunk-dev will remain.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/osgeo4w-package-for-GRASS-7-tp5189077p5189083.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

4

2015-02-21 14:09 GMT+01:00 Martin Landa <landa.martin@gmail.com>:

well, b) is probably too much radical from user POV. Moreover in the
most of Linux distributions the name of GRASS 7 package will be
probably `grass7` and not `grass`.

so probably a) is probably better. Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

5

Hi,

2015-02-21 14:22 GMT+01:00 Helmut Kudrnovsky <hellik@web.de>:

I tend to b), as we may retire the grass6x-lines with grass7.0.1. thus only
grass, grass-dev and grass-trunk-dev will remain.

hm, you are right, I checked again Debian, there is no `grass7`
package [1]. So my plan is:

OSGeo4w:

* grass70 to grass (version 7.0.0)
* grass to grass6 (version 6.4.4)
* grass64-dev to grass6-dev (version 6.4.5svn)
* grass70-dev to grass-dev (version 7.0.1svn)
* grass71-dev to grass-trunk-dev (7.1.svn)

Same for Launchpad.

Any objections? Martin

[1] https://packages.debian.org/search?keywords=grass&searchon=names&suite=all&section=all

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

6

On Sat, Feb 21, 2015 at 2:22 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

Martin Landa wrote

Personally I would vote for b). Any opinion? It's strategic decision,
so please feel free to give me feedback ASAP...

I tend to b), as we may retire the grass6x-lines with grass7.0.1. thus only
grass, grass-dev and grass-trunk-dev will remain.

I personally prefer option b too.

Pietro

7

On Sat, Feb 21, 2015 at 8:09 AM, Martin Landa <landa.martin@gmail.com>
wrote:

2015-02-21 14:01 GMT+01:00 Yann Chemin <ychemin@gmail.com>:
> Regardless of all the rest, I like the idea of moving grass70 -> grass
and grass -> grass6, I feel it kinda makes a statement here, beyond the
actual release, it is just the new state of the software.
>
> But then that means simply +1 for option b)

well, b) is probably too much radical from user POV. Moreover in the
most of Linux distributions the name of GRASS 7 package will be
probably `grass7` and not `grass`.

I have the feeling that Ubuntu/Debian has always names like "grass7", as
you decided in another thread, and then there is a metapackage named like
"grass" which depends on "grass7", or sometimes on the "expected set of
packages" such as "grass7-core", "grass7-gui", "grass7-doc".

8

2015-02-21 15:44 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:

I have the feeling that Ubuntu/Debian has always names like "grass7", as you
decided in another thread, and then there is a metapackage named like
"grass" which depends on "grass7", or sometimes on the "expected set of
packages" such as "grass7-core", "grass7-gui", "grass7-doc".

it doesn't seems to be like that, see clarification [1]. Martin

[1] https://lists.debian.org/debian-gis/2015/02/msg00048.html

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

9

On Sat, Feb 21, 2015 at 7:48 AM, Martin Landa <landa.martin@gmail.com>
wrote:

(option a)

* grass70-dev to grass7-dev (version 7.0.1svn)
* grass71-dev to grass-trunk-dev (7.1.svn)

or

(option b)

* grass64-dev to grass6-dev (version 6.4.5svn)
* grass70-dev to grass-dev (version 7.0.1svn)
* grass71-dev to grass-trunk-dev (7.1.svn)

I don't like grass71-dev and 7.1.svn (or 7.1svn) because we are branching
7.1 from 7.0, not from trunk, right? So, trunk will never become 7.1 (nor
7.2, ...).

However, I don't like grass-trunk-dev (for trunk) and grass-dev (for 70
branch). Doesn't trunk says the same as dev? Most of the projects has
developement code in trunk (or master branch in case of Git). Just few have
special dev/devel/development branch. grass-dev to me sounds like trunk.
Isn't 70 branch in fact stable rather than development?

I quite like grass6-dev for release branch 64 (and for following branches),
grass7-dev for 70 release branch (and following) and grass-dev for trunk
(forever). What is confusing about that is that "-dev" packages on
Debian/Ubuntu (elsewhere?) are for development files (e.g. if you want to
build upon the library) and development versions are solved using different
means (different repositories). This might be confusing if you are
switching systems or writing some general instructions.

Anyway, the complete proposal would be:

* grass6 (latest 6.x release, now 6.4.4)
* grass7 (latest 7.x release, now 7.0.0)
* grass6-dev (release_branch_6* branches)
* grass7-dev (release_branch_7* branches)
* grass-dev (trunk)

Package grass could be synonym for grass6 for compatibility reasons or it
can be synonym for grass7 because this is what is the default and preferred
version of GRASS GIS. Alternatively, grass7 can be just grass which seems a
bit confusing with grass-dev being trunk but it is following the logic of
defaults. Default development version is trunk and that is under grass-dev.
Default release is 7.x and this is under grass.

Later, I might have some alternative suggestion with -daily -nightly
-stable -release -devel -trunk but I have to think about it more.

10

On Sat, Feb 21, 2015 at 9:46 AM, Martin Landa <landa.martin@gmail.com>
wrote:

2015-02-21 15:44 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:
> I have the feeling that Ubuntu/Debian has always names like "grass7", as
you
> decided in another thread, and then there is a metapackage named like
> "grass" which depends on "grass7", or sometimes on the "expected set of
> packages" such as "grass7-core", "grass7-gui", "grass7-doc".

it doesn't seems to be like that, see clarification [1]. Martin

[1] https://lists.debian.org/debian-gis/2015/02/msg00048.html

Hm, I don't understand it. However, compatibility with Linux packaging
conventions would be nice in OSGeo4W. Compatibility with other projects in
OSGeo4W would make sense too. I guess that grass has most complex situation
but is there any general practice?

11

Hi,

2015-02-21 16:27 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:

I don't like grass71-dev and 7.1.svn (or 7.1svn) because we are branching
7.1 from 7.0, not from trunk, right? So, trunk will never become 7.1 (nor
7.2, ...).

hm, VERSION file in trunk says 7.1. I live in impression that relbr70
is just for releasing 7.0.x versions (see the name of the branch).
Later we will create branch relbr71 from trunk and trunk becomes 7.3
and so.

However, I don't like grass-trunk-dev (for trunk) and grass-dev (for 70
branch). Doesn't trunk says the same as dev? Most of the projects has
developement code in trunk (or master branch in case of Git). Just few have
special dev/devel/development branch. grass-dev to me sounds like trunk.
Isn't 70 branch in fact stable rather than development?

yes, we chose package name for daily builds based on QGIS package
`qgis-dev`. I found only two projects in OSGeo4W with daily builds -
GRASS GIS and QGIS. In my eyes, -dev postfix is wrong in this meaning,
so I would agree with you. Since there are no naming rules for OSGeo4W
we could choose eg.:

grass70-dev -> grass-daily or grass-svn
grass71-dev -> grass-trunk-daily or grass-trunk-svn

(btw, grass-dev is eg. used in Debian for packaging development files
(headers, and so on)

I quite like grass6-dev for release branch 64 (and for following branches),
grass7-dev for 70 release branch (and following) and grass-dev for trunk
(forever). What is confusing about that is that "-dev" packages on
Debian/Ubuntu (elsewhere?) are for development files (e.g. if you want to
build upon the library) and development versions are solved using different

Right.

Anyway, the complete proposal would be:

* grass6 (latest 6.x release, now 6.4.4)
* grass7 (latest 7.x release, now 7.0.0)
* grass6-dev (release_branch_6* branches)
* grass7-dev (release_branch_7* branches)
* grass-dev (trunk)

Package grass could be synonym for grass6 for compatibility reasons or it
can be synonym for grass7 because this is what is the default and preferred
version of GRASS GIS. Alternatively, grass7 can be just grass which seems a

I am not sure if it's really needed to create such metapackage. The
simple solution would be enough I would say:

grass (version 7.0.0)
grass6 (version 6.4.4)

Later, I might have some alternative suggestion with -daily -nightly -stable
-release -devel -trunk but I have to think about it more.

See above. Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

12

On 21/02/15 15:03, Martin Landa wrote:

Hi,

2015-02-21 14:22 GMT+01:00 Helmut Kudrnovsky <hellik@web.de>:

I tend to b), as we may retire the grass6x-lines with grass7.0.1. thus only
grass, grass-dev and grass-trunk-dev will remain.

hm, you are right, I checked again Debian, there is no `grass7`
package [1]. So my plan is:

OSGeo4w:

* grass70 to grass (version 7.0.0)
* grass to grass6 (version 6.4.4)
* grass64-dev to grass6-dev (version 6.4.5svn)
* grass70-dev to grass-dev (version 7.0.1svn)
* grass71-dev to grass-trunk-dev (7.1.svn)

+1

Except for grass6-dev: does it really make sense to still publish a -dev version of grass6 ? In my thinking we will be in pure bug fixing mode for grass6 once grass7 is out. I would actually plead to reduce to one grass6 branch on trac with bug-fixes only for that branch and bug-fix releases just being tags of that branch.

Moritz

13

Hi,

2015-02-21 17:45 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:

Except for grass6-dev: does it really make sense to still publish a -dev
version of grass6 ? In my thinking we will be in pure bug fixing mode for
grass6 once grass7 is out. I would actually plead to reduce to one grass6
branch on trac with bug-fixes only for that branch and bug-fix releases just
being tags of that branch.

make sense to me. Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

14

2015-02-21 17:49 GMT+01:00 Martin Landa <landa.martin@gmail.com>:

Except for grass6-dev: does it really make sense to still publish a -dev
version of grass6 ? In my thinking we will be in pure bug fixing mode for
grass6 once grass7 is out. I would actually plead to reduce to one grass6
branch on trac with bug-fixes only for that branch and bug-fix releases just
being tags of that branch.

make sense to me. Martin

to summarize OSGeo4W proposal:

* `grass` will be 7.0.0
* `grass6` will be 6.4.4 (hopefully soon 6.4.5)
* `grass-svn` will be 7.0.1svn (*)
* `grass-trunk-svn` will be 7.1svn
* `grass64-dev` will be removed

Martin

(*) `dev` is really misleading here, so `svn` or `daily` (`svn` sounds
more technical).

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

15

On Sat, Feb 21, 2015 at 6:17 PM, Martin Landa <landa.martin@gmail.com> wrote:

to summarize OSGeo4W proposal:

* `grass` will be 7.0.0
* `grass6` will be 6.4.4 (hopefully soon 6.4.5)
* `grass-svn` will be 7.0.1svn (*)
* `grass-trunk-svn` will be 7.1svn
* `grass64-dev` will be removed

Martin

(*) `dev` is really misleading here, so `svn` or `daily` (`svn` sounds
more technical).

We should follow somewhat the naming scheme in OSGeo4W. Here what QGIS does:

http://trac.osgeo.org/osgeo4w/wiki/pkg-qgis

Packages:

qgis: QGIS Desktop
qgis-server: QGIS Server
qgis-common: common dependencies of qgis/qgis-server
qgis-devel: headers and libraries for development
qgis-oracle-provider: Oracle provider for qgis/qgis-server
qgis-grass-plugin: GRASS plugin for qgis
qgis-globe-plugin: GLOBE plugin for qgis
qgis-full: (extensive) optional dependencies for qgis
qgis-dev: Nightly build of master
qgis-full-dev: (extensive) optional dependencies for qgis-dev
qgis-dev-pdb: debugging symbols for qgis-dev

--> They call it -dev, not -svn.

For the rest, Martin's suggestion is similar.

Markus

16

Markus Neteler wrote

On Sat, Feb 21, 2015 at 6:17 PM, Martin Landa &lt;

landa.martin@

&gt; wrote:

to summarize OSGeo4W proposal:

* `grass` will be 7.0.0
* `grass6` will be 6.4.4 (hopefully soon 6.4.5)
* `grass-svn` will be 7.0.1svn (*)
* `grass-trunk-svn` will be 7.1svn
* `grass64-dev` will be removed

Martin

(*) `dev` is really misleading here, so `svn` or `daily` (`svn` sounds
more technical).

We should follow somewhat the naming scheme in OSGeo4W. Here what QGIS
does:

http://trac.osgeo.org/osgeo4w/wiki/pkg-qgis

Packages:

qgis: QGIS Desktop
qgis-server: QGIS Server
qgis-common: common dependencies of qgis/qgis-server
qgis-devel: headers and libraries for development
qgis-oracle-provider: Oracle provider for qgis/qgis-server
qgis-grass-plugin: GRASS plugin for qgis
qgis-globe-plugin: GLOBE plugin for qgis
qgis-full: (extensive) optional dependencies for qgis
qgis-dev: Nightly build of master
qgis-full-dev: (extensive) optional dependencies for qgis-dev
qgis-dev-pdb: debugging symbols for qgis-dev

--> They call it -dev, not -svn.

For the rest, Martin's suggestion is similar.

I'm always confused by all these OSGeo4W-QGIS. IMHO for OSGeo4W-winGRASS
keep it simple and intuitive.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/osgeo4w-package-for-GRASS-7-tp5189077p5189152.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

17

On Sat, Feb 21, 2015 at 3:49 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Sat, Feb 21, 2015 at 6:17 PM, Martin Landa <landa.martin@gmail.com>
wrote:
> to summarize OSGeo4W proposal:
>
> * `grass` will be 7.0.0
> * `grass6` will be 6.4.4 (hopefully soon 6.4.5)
> * `grass-svn` will be 7.0.1svn (*)
> * `grass-trunk-svn` will be 7.1svn
> * `grass64-dev` will be removed
>
> Martin
>
> (*) `dev` is really misleading here, so `svn` or `daily` (`svn` sounds
> more technical).

We should follow somewhat the naming scheme in OSGeo4W. Here what QGIS
does:

http://trac.osgeo.org/osgeo4w/wiki/pkg-qgis

Packages:

qgis: QGIS Desktop
qgis-server: QGIS Server
qgis-common: common dependencies of qgis/qgis-server
qgis-devel: headers and libraries for development
qgis-oracle-provider: Oracle provider for qgis/qgis-server
qgis-grass-plugin: GRASS plugin for qgis
qgis-globe-plugin: GLOBE plugin for qgis
qgis-full: (extensive) optional dependencies for qgis
qgis-dev: Nightly build of master
qgis-full-dev: (extensive) optional dependencies for qgis-dev
qgis-dev-pdb: debugging symbols for qgis-dev

--> They call it -dev, not -svn.

In fact, they call it -dev not -trunk-svn. The difference is that QGIS

does not have two "development" versions. Perhaps we also don't need a
package for 70 branch (later replaced by 71, 72, ...). Perhaps it is enough
to have packages just trunk and official releases (now 7.0.0 and 6.4.4).

The issue with QGIS naming is that -dev and -devel is complete opposite
meaning the for Debian packaging (devel repository versus dev packages).
Please correct if I'm wrong. But anyway, with -dev and -devel it is hard to
say which one is which if you don't see the description.

For the rest, Martin's suggestion is similar.

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

18

On Sat, Feb 21, 2015 at 12:17 PM, Martin Landa <landa.martin@gmail.com>
wrote:

2015-02-21 17:49 GMT+01:00 Martin Landa <landa.martin@gmail.com>:
>> Except for grass6-dev: does it really make sense to still publish a -dev
>> version of grass6 ? In my thinking we will be in pure bug fixing mode
for
>> grass6 once grass7 is out. I would actually plead to reduce to one
grass6
>> branch on trac with bug-fixes only for that branch and bug-fix releases
just
>> being tags of that branch.
>
> make sense to me. Martin

to summarize OSGeo4W proposal:

* `grass` will be 7.0.0
* `grass6` will be 6.4.4 (hopefully soon 6.4.5)
* `grass-svn` will be 7.0.1svn (*)
* `grass-trunk-svn` will be 7.1svn
* `grass64-dev` will be removed

Martin

(*) `dev` is really misleading here, so `svn` or `daily` (`svn` sounds
more technical).

I don't like svn in package names. Daily expresses much better what it is.
It is not the current state of svn, it is a daily build. With leaving out
the daily builds of current release branch (now 70), it would be just:

* `grass` - latest stable release
* `grass6` - latest stable release of 6.x series
* `grass-daily` - daily build of trunk

In my suggestion I suppose that we don't need to package daily builds of
current release branch (now 70). However, I'm not sure how to deal with
betas and RCs. Should they be also accessible just through standalone
installer? Or are they considered as "latest stable release" and thus for
example, 7.0.1RC1 would replace 7.0.0 in package `grass`?

19

On Sat, Feb 21, 2015 at 11:11 AM, Martin Landa <landa.martin@gmail.com>
wrote:

> I don't like grass71-dev and 7.1.svn (or 7.1svn) because we are branching
> 7.1 from 7.0, not from trunk, right? So, trunk will never become 7.1 (nor
> 7.2, ...).

hm, VERSION file in trunk says 7.1. I live in impression that relbr70
is just for releasing 7.0.x versions (see the name of the branch).
Later we will create branch relbr71 from trunk and trunk becomes 7.3
and so.

I'm not really sure but I think this is how it should be but some
discussions on PSC showed that GRASS GIS is using different scheme where
you branch new release branch from existing release branch. The
disadvantage is that that you have to backport every single commit and this
is why I was against. The advantage is that the new release branch is as
stable as the previous one was. But then you probably don't need to create
new branch at all. Perhaps it was just a misunderstanding, the discussion
was tough.

20

wenzeslaus wrote

On Sat, Feb 21, 2015 at 12:17 PM, Martin Landa &lt;

landa.martin@

&gt;
wrote:

2015-02-21 17:49 GMT+01:00 Martin Landa &lt;

landa.martin@

&gt;:

>> Except for grass6-dev: does it really make sense to still publish a
-dev
>> version of grass6 ? In my thinking we will be in pure bug fixing mode
for
>> grass6 once grass7 is out. I would actually plead to reduce to one
grass6
>> branch on trac with bug-fixes only for that branch and bug-fix
releases
just
>> being tags of that branch.
>
> make sense to me. Martin

to summarize OSGeo4W proposal:

* `grass` will be 7.0.0
* `grass6` will be 6.4.4 (hopefully soon 6.4.5)
* `grass-svn` will be 7.0.1svn (*)
* `grass-trunk-svn` will be 7.1svn
* `grass64-dev` will be removed

Martin

(*) `dev` is really misleading here, so `svn` or `daily` (`svn` sounds
more technical).

I don't like svn in package names. Daily expresses much better what it is.
It is not the current state of svn, it is a daily build. With leaving out
the daily builds of current release branch (now 70), it would be just:

* `grass` - latest stable release
* `grass6` - latest stable release of 6.x series
* `grass-daily` - daily build of trunk

In my suggestion I suppose that we don't need to package daily builds of
current release branch (now 70). However, I'm not sure how to deal with
betas and RCs. Should they be also accessible just through standalone
installer? Or are they considered as "latest stable release" and thus for
example, 7.0.1RC1 would replace 7.0.0 in package `grass`?

_______________________________________________
grass-dev mailing list

grass-dev@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-dev

why not just retire OSGeo4W-grass6 after grass 7.0.1 will be released?

IMHO regarding testing/improving g7 by devs _and_ users, it's better to have
relbranch7 dailys ready in OSGeo4W than fading out grass6.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/osgeo4w-package-for-GRASS-7-tp5189077p5189160.html
Sent from the Grass - Dev mailing list archive at Nabble.com.