Packaging for Archlinux and releases
Leo Gaspard
I am currently packaging the plugins available at http://code.google.com/p/lh-vim/
for Archlinux.
I would like to get approval from you, Luc.
But I wonder : the home page says that "I'll announce new releases of
these plugins in lh-vim-users."
However, it looks like there have been very few messages on this
group.
Will I receive releases notifications by subscribing to this group ?
Thanks in advance,
Leo "Ekleog" Gaspard
Luc Hermitte
I am currently packaging the plugins available at http://code.google.com/p/lh-vim/
for Archlinux.
I would like to get approval from you, Luc.
You have my approval.
But be aware most plugins have strong dependencies to other plugins. If I haven't made any mistakes, all dependencies are specified in vim-addon-manager format (you'll find a {plugin-name}-addon-info.txt file in each trunk).
To my shame I must also admit that some documentations are not in sync with the features implemented in the plugins. Sometimes there isn't any relevant documentation at all (this is the case of the central lh-dev library which is required by lh-cpp and lh-refactor).
But I wonder : the home page says that "I'll announce new releases of
these plugins in lh-vim-users."
However, it looks like there have been very few messages on this
group.
Will I receive releases notifications by subscribing to this group ?
Indeed. My mistake. As there are very few members I must admit I've never emitted any release notifications.
The fact that I often commit small changes with no "official" releases doesn't help either. ^^'
Let me know if you need proper releases instead of my unstructured commits. I can't promise anything regarding the documentation though :(
Regards,
Luc Hermitte
Ekleog
> Hello Leo
>
>
> I am currently packaging the plugins available at
> http://code.google.com/p/lh-vim/
> for Archlinux.
> I would like to get approval from you, Luc.
>
>
> You have my approval.
Thanks !
> But be aware most plugins have strong dependencies to other plugins. If I
> haven't made any mistakes, all dependencies are specified in vim-addon-manager
> format (you'll find a {plugin-name}-addon-info.txt file in each trunk).
BTW, should I call lhBrackets lh-brackets or lh-map-tools ? lh-map-tools is more
used on the wiki but in the source it is more lh-brackets.
> To my shame I must also admit that some documentations are not in sync with the
> features implemented in the plugins. Sometimes there isn't any relevant
> documentation at all (this is the case of the central lh-dev library which is
> required by lh-cpp and lh-refactor).
>
> But I wonder : the home page says that "I'll announce new releases of
> these plugins in lh-vim-users."
> However, it looks like there have been very few messages on this
> group.
> Will I receive releases notifications by subscribing to this group ?
>
>
> Indeed. My mistake. As there are very few members I must admit I've never
> emitted any release notifications.
> The fact that I often commit small changes with no "official" releases doesn't
> help either. ^^'
>
> Let me know if you need proper releases instead of my unstructured commits. I
> can't promise anything regarding the documentation though :(
If it was possible to release at least a vimball per plugin, it would be
perfect. I would just have to adapt the vimball to the pkgbuild.
And, on some time, maybe would releasing a vimball help ? Some script to do that
each X weeks (e.g. 10), if the commits are unstructured by nature.
Or, if you explain me how to build the vimball from the mkVba directory, I could
do it myself, and send you the files (or place them directly on google code if
you give me the rights to do so).
But I tried opening the .vim file in mkVba/ and runnning :source % and it didn't
work (at least for lh-cpp, I didn't try for the others yet).
I must admit that having proper releases would ease the process of updating lh-vim !
>
> Regards,
>
> --
> Luc Hermitte
Best regards and see you (on developpez.net ?),
Leo "Ekleog" Gaspard
Ekleog
I thought of calling them based on their directories from your svn tree :
lh-btw
lh-sir
lh-ut
lh-cpp
lh-dev
lh-map-tools
mu-template (the only one not starting by lh- ; as lh-mu-template ... I think
mu-template sounds better)
lh-refactor
lh-system-tools
lh-tags
lh-vim-lib
What do you think about this ?
Bests,
Leo Gaspard
Luc Hermitte
On 29/02/2012 17:38, Luc Hermitte wrote:BTW, should I call lhBrackets lh-brackets or lh-map-tools ? lh-map-tools is more used on the wiki but in the source it is more lh-brackets.
I think it would be best to use the same names that the ones I've used for VAM.
-> lh-vim-lib, lh-brackets, lh-tags, lh-dev, lh-cpp, lh-refactor, mu-template
Then there are still build-tools-wrapper, search-in-runtime, UT and system-tools.... If we know that these "packages" are vim only, I guess we can leave them with theses names. AFAIK, I'm the only one to have come with such plugins (well, SiR has alternatives (command-T and fuzzyfinder)).
I see no problem to prepend the plugin names with my initials though. It's OK with me if you think it's more in the spirit of arch-linux packages.
NB: lh-map-tools is the initial name of the API I wrote ages ago to have smart-snippets. Then, I merged it with my bracketing-system. Hence lh-brackets. It's not that good, but I had no betters idea at the time. Regarding the lhUppercase, it comes from the wiki pages naming policy.
If it was possible to release at least a vimball per plugin, it would be perfect. I would just have to adapt the vimball to the pkgbuild.Let me know if you need proper releases instead of my unstructured commits. I
can't promise anything regarding the documentation though :(
If the pkgbuild supports dependencies, why not -- the absence of native support of dependencies is one of the reasons I've abandoned vimballs.
And, on some time, maybe would releasing a vimball help ?
I'm not sure to see what you are referring to by "vimball help".
Some script to do that each X weeks (e.g. 10), if the commits are unstructured by nature.
Or, if you explain me how to build the vimball from the mkVba directory, I could do it myself, and send you the files (or place them directly on google code if you give me the rights to do so).
That could be done. I'll have a look at it this afternoon.
But I tried opening the .vim file in mkVba/ and runnning :source % and it didn't work (at least for lh-cpp, I didn't try for the others yet).
That's odd. You've understood how it's meant to be used. But why this haven't worked ?
Hum... it's likely that rtp isn't correctly set. Try the same script for lh-refactor. If this works, I'll have to use the "new" way of doing things with the old mkvba-scripts.
I must admit that having proper releases would ease the process of updating lh-vim !
I understand.
BTW, I remember that I have a "little" thing to do: I have to specify the licences for mu-template, and the licence-exceptions for the generated code.
Another thing: there are a few script in the misc section that could be interesting to distribute. I'm thinking in particular to local_vimrc (which isn't documented yet).
Best regards and see you (on developpez.net ?),
Indeed ^^
A+
Luc Hermitte
Ekleog
> Hello,
>
> 2012/2/29 Ekleog <ekl...@gmail.com <mailto:ekl...@gmail.com>>
>
> On 29/02/2012 17:38, Luc Hermitte wrote:
> BTW, should I call lhBrackets lh-brackets or lh-map-tools ? lh-map-tools is
> more used on the wiki but in the source it is more lh-brackets.
>
>
> I think it would be best to use the same names that the ones I've used for VAM.
> -> lh-vim-lib, lh-brackets, lh-tags, lh-dev, lh-cpp, lh-refactor, mu-template
> Then there are still build-tools-wrapper, search-in-runtime, UT and
> system-tools.... If we know that these "packages" are vim only, I guess we can
> leave them with theses names. AFAIK, I'm the only one to have come with such
> plugins (well, SiR has alternatives (command-T and fuzzyfinder)).
> I see no problem to prepend the plugin names with my initials though. It's OK
> with me if you think it's more in the spirit of arch-linux packages.
Archlinux packages don't really have a naming policy. But I was afraid
search-in-runtime or build-tools-wrapper would be likely to conflict with other
archlinux packages, as they are generic names.
So, maybe should I call them vim-build-tools-wrapper ?
> NB: lh-map-tools is the initial name of the API I wrote ages ago to have
> smart-snippets. Then, I merged it with my bracketing-system. Hence lh-brackets.
> It's not that good, but I had no betters idea at the time. Regarding the
> lhUppercase, it comes from the wiki pages naming policy.
>
Thanks for the precision !
> Let me know if you need proper releases instead of my unstructured
> commits. I
> can't promise anything regarding the documentation though :(
>
>
> If it was possible to release at least a vimball per plugin, it would be
> perfect. I would just have to adapt the vimball to the pkgbuild.
>
>
> If the pkgbuild supports dependencies, why not -- the absence of native support
> of dependencies is one of the reasons I've abandoned vimballs.
Of course do pkgbuilds support dependencies - what would a package manager be
otherwise ?
The issue with VAM is that it builds from the SVN, and it is better practice to
have a reproducible build : calling two times makepkg on the same pkgbuild
should give the exact same package. But building from svn doesn't allow this to
be the case ; except using tags, but I don't know how to make vam to use a svn
tag and not the bleeding edge.
> And, on some time, maybe would releasing a vimball help ?
>
>
> I'm not sure to see what you are referring to by "vimball help".
I meant : maybe would it help, to release a vimball. (english's priority of
operation is ambiguous, isn't it ?)
> Some script to do that each X weeks (e.g. 10), if the commits are
> unstructured by nature.
>
> Or, if you explain me how to build the vimball from the mkVba directory, I
> could do it myself, and send you the files (or place them directly on google
> code if you give me the rights to do so).
>
>
> That could be done. I'll have a look at it this afternoon.
Thanks !
> But I tried opening the .vim file in mkVba/ and runnning :source % and it
> didn't work (at least for lh-cpp, I didn't try for the others yet).
>
>
> That's odd. You've understood how it's meant to be used. But why this haven't
> worked ?
> Hum... it's likely that rtp isn't correctly set. Try the same script for
> lh-refactor. If this works, I'll have to use the "new" way of doing things with
> the old mkvba-scripts.
Looks like lh-cpp's mkVba was broken yesterday, so. (I didn't try again today.)
I tried with search-in-runtime, and it worked.
> I must admit that having proper releases would ease the process of updating
> lh-vim !
>
>
> I understand.
> BTW, I remember that I have a "little" thing to do: I have to specify the
> licences for mu-template, and the licence-exceptions for the generated code.
Oh, all the source code isn't under GPLv2 ? That's what's written on google code.
BTW, pkgbuilds allow not to have to copy the license on each package, as long as
they are enough used and present in a shared /usr/share/licenses/common/ (which
is the case for most licenses, except MIT e.g., which requires a custom
copyright in the license text).
> Another thing: there are a few script in the misc section that could be
> interesting to distribute. I'm thinking in particular to local_vimrc (which
> isn't documented yet).
The issue with local_vimrc is that it must be placed in each project directory.
So it isn't easy to package it. But maybe could I write some function allowing
to type something like :initproject to generate a local_vimrc. And, then, the
script running this command may be packaged.
BTW, it would be useful to call it .local_vimrc, because of the spam when
running ls - but that shouldn't be too difficult to do, I just have to try
reading the source code.
> A+
> --
> Luc Hermitte
A+
Leo Gaspard
Luc Hermitte
Archlinux packages don't really have a naming policy. But I was afraid search-in-runtime or build-tools-wrapper would be likely to conflict with other archlinux packages, as they are generic names.
So, maybe should I call them vim-build-tools-wrapper ?
Sounds good to me.
How other vim plugins (like command-t, snipmate, etc) are named within arch-linux ?
The issue with VAM is that it builds from the SVN, and it is better practice to have a reproducible build : calling two times makepkg on the same pkgbuild should give the exact same package. But building from svn doesn't allow this to be the case ; except using tags, but I don't know how to make vam to use a svn tag and not the bleeding edge.
This should be possible, but in any cases I'll have to tags my sources -- I haven't done it in a long time.
Thanks !Or, if you explain me how to build the vimball from the mkVba directory, I
could do it myself, and send you the files (or place them directly on google
code if you give me the rights to do so).
That could be done. I'll have a look at it this afternoon.
Looks like lh-cpp's mkVba was broken yesterday, so. (I didn't try again today.)
I tried with search-in-runtime, and it worked.
OK. It's just that I've never upgraded lh-cpp's mkVba in a very long time -- nor checked that all files are listed.
Oh, all the source code isn't under GPLv2 ? That's what's written on google code.BTW, I remember that I have a "little" thing to do: I have to specify the
licences for mu-template, and the licence-exceptions for the generated code.
It's more complex than that. To be pedantic, I have an issue similar to what GCC and GNU stdlib++ have with licences.
The code generated with mu-template (lh-cpp, and lh-refactor as well) shall not be under GPL2+ licence -- even if mu-template's code is in under GPL2.
Otherwise, anyone using my plugins have to release their code under GPL. That is not acceptable.
Some snippets (for, if, etc) shall be in the public domain, other I want them under Boost Software Licence. And the documentation should be under one of the creative common licences, etc.
The issue with local_vimrc is that it must be placed in each project directory.Another thing: there are a few script in the misc section that could be
interesting to distribute. I'm thinking in particular to local_vimrc (which
isn't documented yet).
No. The plugin is meant to be in {rtp}/plugin.
Then local vimrcs need to be in each project (/subproject) directory(/ies).
So it isn't easy to package it. But maybe could I write some function allowing to type something like :initproject to generate a local_vimrc. And, then, the script running this command may be packaged.
BTW, it would be useful to call it .local_vimrc, because of the spam when running ls - but that shouldn't be too difficult to do, I just have to try reading the source code.
Just set g:local_vimrc to whatever you prefer, like '.vimrc.project' for instance.
Luc Hermitte
Ekleog
>
> Archlinux packages don't really have a naming policy. But I was afraid
> search-in-runtime or build-tools-wrapper would be likely to conflict with
> other archlinux packages, as they are generic names.
> So, maybe should I call them vim-build-tools-wrapper ?
>
>
> Sounds good to me.
> How other vim plugins (like command-t, snipmate, etc) are named within arch-linux ?
Command-t is named vim-command-t.
Snipmate does not have any package.
Molokai (my favorite colors) is named vim-molokai.
So, I believe it's standard to name packages vim-xxx. But I wonder whether I
should also call the other plugins vim-lh-xxx. Because it would make
vim-lh-vim-lib, which isn't really attractive !
BTW, I thought I would name the group of packages (installing a group installs
all the packages in it) lh-vim.
> The issue with VAM is that it builds from the SVN, and it is better practice
> to have a reproducible build : calling two times makepkg on the same
> pkgbuild should give the exact same package. But building from svn doesn't
> allow this to be the case ; except using tags, but I don't know how to make
> vam to use a svn tag and not the bleeding edge.
>
>
> This should be possible, but in any cases I'll have to tags my sources -- I
> haven't done it in a long time.
So, the issue remains the same.
> Or, if you explain me how to build the vimball from the mkVba
> directory, I
> could do it myself, and send you the files (or place them directly
> on google
> code if you give me the rights to do so).
>
> That could be done. I'll have a look at it this afternoon.
>
>
> Thanks !
>
>
>
> Looks like lh-cpp's mkVba was broken yesterday, so. (I didn't try again today.)
> I tried with search-in-runtime, and it worked.
>
>
> OK. It's just that I've never upgraded lh-cpp's mkVba in a very long time -- nor
> checked that all files are listed.
So it'll be better soon. Fine !
I could even do it myself, and just send you a patch.
I could also compile the vimball myself - as I now know what was the issue - but
I would need your help for knowing when to release a new version, and which
version number to give it.
> BTW, I remember that I have a "little" thing to do: I have to specify the
> licences for mu-template, and the licence-exceptions for the generated code.
>
>
> Oh, all the source code isn't under GPLv2 ? That's what's written on google
> code.
>
>
> It's more complex than that. To be pedantic, I have an issue similar to what GCC
> and GNU stdlib++ have with licences.
> The code generated with mu-template (lh-cpp, and lh-refactor as well) shall not
> be under GPL2+ licence -- even if mu-template's code is in under GPL2.
> Otherwise, anyone using my plugins have to release their code under GPL. That is
> not acceptable.
> Some snippets (for, if, etc) shall be in the public domain, other I want them
> under Boost Software Licence. And the documentation should be under one of the
> creative common licences, etc.
OK, so ...
Will you distribute a license file within each of the directories of your projects ?
I must however admit that it's a lot of work for such legal duties ...
> Another thing: there are a few script in the misc section that could be
> interesting to distribute. I'm thinking in particular to local_vimrc (which
> isn't documented yet).
>
>
> The issue with local_vimrc is that it must be placed in each project directory.
>
>
> No. The plugin is meant to be in {rtp}/plugin.
> Then local vimrcs need to be in each project (/subproject) directory(/ies).
Oh, I meant the local vimrcs.
That is, it's not hard to distribute the plugin meant to be in {rtp}/plugin.
But we should then provide a way to "generate" the local vimrc in the project
directory, for an ease of use - else, from where should people copy the local
vimrc ? From /usr/share/vim/vimfiles/ ? Quite long to type, isn't it ?
With a personal installation, it's possible to copy the file from some near
directory project, but the issue is that it's not possible for packages that
need to place files on some specified subdirectories.
But a single function copying the local vimrc to the current directory would be
enough !
> So it isn't easy to package it. But maybe could I write some function
> allowing to type something like :initproject to generate a local_vimrc. And,
> then, the script running this command may be packaged.
>
> BTW, it would be useful to call it .local_vimrc, because of the spam when
> running ls - but that shouldn't be too difficult to do, I just have to try
> reading the source code.
>
>
> Just set g:local_vimrc to whatever you prefer, like '.vimrc.project' for instance.
Thanks, didn't know that trick !
>
> --
> Luc Hermitte
I know I'm giving you a lot of work, and I'm sorry of this.
I just hope it'll be possible to overcome all those difficulties !
See you,
Leo Gaspard
Luc Hermitte
On 01/03/2012 19:15, Luc Hermitte wrote:Command-t is named vim-command-t.
Archlinux packages don't really have a naming policy. But I was afraid
search-in-runtime or build-tools-wrapper would be likely to conflict with
other archlinux packages, as they are generic names.
So, maybe should I call them vim-build-tools-wrapper ?
Sounds good to me.
How other vim plugins (like command-t, snipmate, etc) are named within arch-linux ?
Snipmate does not have any package.
Molokai (my favorite colors) is named vim-molokai.
So, I believe it's standard to name packages vim-xxx.
Perfect. This is fine by me.
But I wonder whether I should also call the other plugins vim-lh-xxx. Because it would make vim-lh-vim-lib, which isn't really attractive !
Indeed. I understand. For the sake of the packaging, there is still vim-lh-lib if you prefer. This won't betray the identity of this library.
BTW, I thought I would name the group of packages (installing a group installs all the packages in it) lh-vim.
That sounds fine.
So, the issue remains the same.The issue with VAM is that it builds from the SVN, and it is better practice
to have a reproducible build : calling two times makepkg on the same
pkgbuild should give the exact same package. But building from svn doesn't
allow this to be the case ; except using tags, but I don't know how to make
vam to use a svn tag and not the bleeding edge.
This should be possible, but in any cases I'll have to tags my sources -- I
haven't done it in a long time.
If you mean that I have to decide from time to time: "now there is a new release". Yes indeed.
For instance, I've been particularly lazy with lh-cpp and build-tool-wrappers that need a consequent documentation effort (and even a refactoring effort as well). That's why there haven't been any official release in ages.
So it'll be better soon. Fine !OK. It's just that I've never upgraded lh-cpp's mkVba in a very long time -- nor
checked that all files are listed.
I could even do it myself, and just send you a patch.
I could also compile the vimball myself - as I now know what was the issue - but I would need your help for knowing when to release a new version, and which version number to give it.
I'm currently fixing the mkvba scripts. A few have been done.
[licences]
It's more complex than that. To be pedantic, I have an issue similar to what GCC
and GNU stdlib++ have with licences.
The code generated with mu-template (lh-cpp, and lh-refactor as well) shall not
be under GPL2+ licence -- even if mu-template's code is in under GPL2.
Otherwise, anyone using my plugins have to release their code under GPL. That is
not acceptable.
Some snippets (for, if, etc) shall be in the public domain, other I want them
under Boost Software Licence. And the documentation should be under one of the
creative common licences, etc.
OK, so ...
Will you distribute a license file within each of the directories of your projects ?
I must however admit that it's a lot of work for such legal duties ...
I've been lazy once again. For now I've patched lh-cpp.README to reflect the intended licences.
I'll be more precise someday in the future. I'll do something similar with mu-template.
Oh, I meant the local vimrcs.
That is, it's not hard to distribute the plugin meant to be in {rtp}/plugin.
But we should then provide a way to "generate" the local vimrc in the project directory, for an ease of use - else, from where should people copy the local vimrc ? From /usr/share/vim/vimfiles/ ? Quite long to type, isn't it ?
Not exactly. This is mu-template's job. It will recognize the name of the script and propose typical (empty) rules -- it does much more than that: try to open a new ftplugin, a new plugin, or a new autoload-plugin.
Someday, I want to write a guide about local_vimrc for real C++ projects.
Unfortunately, every time I start a new project, I fix little things here and there. ^^'
With a personal installation, it's possible to copy the file from some near directory project, but the issue is that it's not possible for packages that need to place files on some specified subdirectories.
That should not be the responsibility of a packaging system, but of a plugin intended to define and maintain what projects are.
I know I'm giving you a lot of work, and I'm sorry of this.
I just hope it'll be possible to overcome all those difficulties !
It's mainly time difficulties. There are not that hard to overcome. Just very long ...
--
Luc Hermitte
Ekleog
> 2012/3/1 Ekleog <ekl...@gmail.com <mailto:ekl...@gmail.com>>
>
> [... About package naming]
>
> The issue with VAM is that it builds from the SVN, and it is better
> practice
> to have a reproducible build : calling two times makepkg on the same
> pkgbuild should give the exact same package. But building from svn
> doesn't
> allow this to be the case ; except using tags, but I don't know how
> to make
> vam to use a svn tag and not the bleeding edge.
>
>
> This should be possible, but in any cases I'll have to tags my sources -- I
> haven't done it in a long time.
>
>
> So, the issue remains the same.
>
>
> If you mean that I have to decide from time to time: "now there is a new
> release". Yes indeed.
> For instance, I've been particularly lazy with lh-cpp and build-tool-wrappers
> that need a consequent documentation effort (and even a refactoring effort as
> well). That's why there haven't been any official release in ages.
I just saw you released v1.1.0 of lh-cpp (not vimball'd, but that's all the same).
Cool !
> OK. It's just that I've never upgraded lh-cpp's mkVba in a very long
> time -- nor
> checked that all files are listed.
>
>
> So it'll be better soon. Fine !
> I could even do it myself, and just send you a patch.
>
> I could also compile the vimball myself - as I now know what was the issue -
> but I would need your help for knowing when to release a new version, and
> which version number to give it.
>
>
> I'm currently fixing the mkvba scripts. A few have been done.
Well ... I'll try to package them into vimballs, and I'll send you the result of
the build on this mailing list, so you can place them in the download section
(it could be useful for non-archlinuxian non-vam-inhabited people discovering
your projects, as vimballs don't require anything to install).
> [... licences]
>
> OK, so ...
> Will you distribute a license file within each of the directories of your
> projects ?
> I must however admit that it's a lot of work for such legal duties ...
>
>
> I've been lazy once again. For now I've patched lh-cpp.README to reflect the
> intended licences.
> I'll be more precise someday in the future. I'll do something similar with
> mu-template.
> [...]
OK, so I'll have to wait before sending the packages : the readme isn't present
anywhere in the packages, as there is no place I could put them in and make the
user know they are here.
> Oh, I meant the local vimrcs.
> That is, it's not hard to distribute the plugin meant to be in {rtp}/plugin.
> But we should then provide a way to "generate" the local vimrc in the
> project directory, for an ease of use - else, from where should people copy
> the local vimrc ? From /usr/share/vim/vimfiles/ ? Quite long to type, isn't it ?
>
>
> Not exactly. This is mu-template's job. It will recognize the name of the script
> and propose typical (empty) rules -- it does much more than that: try to open a
> new ftplugin, a new plugin, or a new autoload-plugin.
Oh. Never discovered that !
Indeed, I never tried to open a new local vimrc ... Shame on me !
> Someday, I want to write a guide about local_vimrc for real C++ projects.
> Unfortunately, every time I start a new project, I fix little things here and
> there. ^^'
Sounds like me. Except I've never gone through a project as big as lh-vim !
(started, yes, finished, not)
> [...]
> I know I'm giving you a lot of work, and I'm sorry of this.
> I just hope it'll be possible to overcome all those difficulties !
>
>
> It's mainly time difficulties. There are not that hard to overcome. Just very
> long ...
So, I'll have to be patient enough !
Cheers,
Leo Gaspard
Ekleog
I joined two files.
The .tar.xz is the built package. It contains all the files that should be added
to the system, plus a .PKGINFO and a .INSTALL that indicate additional
informations for the package manager. You may read both, they are text-only files.
The .tar.gz is the source package : the PKGBUILD, the .install and a vimball
containing the source. The normal procedure is to make the pkgbuild to
auto-download the vimball (or the archive containing the source) from the
project website, but as there are no vimball up-to-date on the website I
included a one I built from the SVN.
The more interesting files for you to see are the files in the .tar.gz ; as
these are the ones I wrote : the .tar.xz is the makepkg'd package.
Is the thing I wrote what you intended ? (I wrote it some days ago, and just
modified it to fit the last changes : as the license is simply GPLv2 for
everything, it does not cause any issue with the package manager.)
What do you think about this ?
Hoping this is what you expect,
Leo Gaspard
Luc Hermitte
Thinking about the licensing issue, I've decided to migrate to GPL3 with exception for generated code.
I'll have everything to repackage.
Sorry.
What do you think about this ?
I trust you with the archlinux packaging. I don't have precise expectations on the subject.
I'll just need you to wait till next week, the time I fix the licenses.
A+
--
Luc Hermitte
Ekleog
> Hi,> [...]
>
> Thinking about the licensing issue, I've decided to migrate to GPL3 with
> exception for generated code.
> I'll have everything to repackage.
> Sorry.
That's not an issue for me : I've just one line to edit in the pkgbuild,
changing 'GLP2' to 'GPL3', as both are common licences.
About the exception for generated code, it will be a somewhat more complicated
task - but it will be doable as far as a license file (or more, if needed) per
project is available.
BTW, I just checked autoconf's license, it is just composed of a
COPYING.EXCEPTION, which is really similar to the one you just posted to the
wiki page.
So, when packaging, I think I'll just copy-and-paste it as a license exception,
and put that in the appropriate directory
(/usr/share/licenses/[pkgname]/COPYING.EXCEPTION) in order to mimic autoconf's
license - and put as a license 'GPL3','custom' ; still like autoconf.
Is that OK ?
> [...]
Cheers,
Leo Gaspard
herm...@free.fr
Hello Leo,
Just a little mail to say that I'm in the slow process of repackaging everything.
On my way, I'm trying to update lh-cpp and mu-template documentations. Hence it takes times.
Regards
--
Luc Hermitte
http://lh-vim.googlecode.com/
Ekleog
>
> Hello Leo,
>
> Just a little mail to say that I'm in the slow process of repackaging everything.
> On my way, I'm trying to update lh-cpp and mu-template documentations. Hence it takes times.
>
> Regards
>
>
OK, thanks !
BTW, I read the READMEs, and I think vim-lh-lib, vim-system-tools, vim-refactor,
vim-lh-map-tools, vim-lh-dev and vim-ut, and I think these are license-ready.
So, should I start to package them now, or should I wait a bit longer ?
However, vim-lh-cpp and vim-mu-template do have READMEs files, but do not
contain enough legal information (I think). I mean, it doesn't allow us to know
exactly which license apply to the generated code (should "license exception"
mean public domain ?). vim-lh-cpp is more clear, but unfortunately doesn't state
what the license exception is.
Finally, vim-lh-tags, lh-search-in-runtime and lh-build-tools-wrapper don't
provide a license file, so I can't package them, even if I wanted to do so.
A last question about the "misc" directory in your svn structure : I think I
shouldn't package it, should I ?
Just to say I'm happy of seeing all this work on my preferred vim plugins, and
impatient of packaging it !
Bests,
Leo Gaspard
Luc Hermitte
BTW, I read the READMEs, and I think vim-lh-lib, vim-system-tools, vim-refactor, vim-lh-map-tools, vim-lh-dev and vim-ut, and I think these are license-ready. So, should I start to package them now, or should I wait a bit longer ?
Just a little bit longer.
I'd like to update the version numbers to mark a major change : all the licensing stuff.
Unless I add a licence file to each of them, lh-refactor should be ready. And I'm afraid it's the only one. ^^'
lh-cpp still needs a lot of documenting effort.
However, vim-lh-cpp and vim-mu-template do have READMEs files, but do not contain enough legal information (I think). I mean, it doesn't allow us to know exactly which license apply to the generated code (should "license exception" mean public domain ?). vim-lh-cpp is more clear, but unfortunately doesn't state what the license exception is.
AFAIK "public domain" is quite unpractical as it has no legal ground in France for instance.
When you say "doesn't state what the license exception is.", do you mean the text on the google-code wiki is unclear, or is it because it is not provided with the plugins.
Finally, vim-lh-tags, lh-search-in-runtime and lh-build-tools-wrapper don't provide a license file, so I can't package them, even if I wanted to do so.
I guess that haven't had the time to work on them yet.
A last question about the "misc" directory in your svn structure : I think I shouldn't package it, should I ?
No, that would be impractical, the chaos reign over there. Someday I'll get local_vimrc out of there as it need a tutorial explaining why it is a must-have, and how to fill it.
Just to say I'm happy of seeing all this work on my preferred vim plugins, and impatient of packaging it !
:)
Luc Hermitte