Debian Packaging

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Debian Packaging

Israel-28
Hey everyone,
The Debian Edu team contacted me, and want me to help them with
packaging!!  Hurray we will finally have a Debian package that is up to
date!!

In my conversation with Petter Reinholdtsen from Debian Edu, he
commented that our recent changes to create the debian folder would
probably lead to issues later on.  So with that in mind I think it would
be wise to remove the newly added things, but keep the desktop file to
be generated by lmms.  If anyone disagrees then I am open to reasons why.

@Tres, I updated my branch with this change

--
Regards


------------------------------------------------------------------------------
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: Debian Packaging

Tres Finocchiaro

Cause what problems?  Will you be the packager?

Great news we'll have an update mirror, but the changes have been very well thought out and the dev team could benefit from and appreciate a proper explanation over at https://github.com/LMMS/lmms/pull/2298 as to why Debian packaging suffers when some of the helper files and scripts are in our codebase.


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: Debian Packaging

Tobias Doerffel-2
Hi,

helper scripts are no problem as long as they're not within the debian
directory. This directory should not exist for avoiding conflicts as
the diff.gz of debian packages should contain a patch which creates
all required files. If e.g. both upstream and Debian packagers modify
the package and thus the changelog, it's likely there will be actual
conflicts. So after all, do not touch packagers work and everything
will be fine ;-)

Toby

------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: Debian Packaging

Tres Finocchiaro
Toby,

Thanks kindly.  I think the scenario that you are describing is correct... In some areas Israel was explicitly creating `/build/debian/` and placing files there, e.g:

Israel,

I'm not sure how manual the packaging process is for you today, but I strongly advise to take as much information from our build process as possible to be fed into the Debian packaging process.

At a glance it appears a lot of it should be removed, but if this leaves you maintaining a list of authors, homepage, project name, project description, you may decide to find a place to configure this information that can easily be picked up by the build process.

The good news is that removing the `cmake/debian` stuff makes the open PR much easier for us to merge since there are much less changes to be approved.  I'll put a few final comments on it now so that we can get this stuff integrated.

-Tres




On Wed, Sep 23, 2015 at 9:40 AM, Tobias Doerffel <[hidden email]> wrote:
Hi,

helper scripts are no problem as long as they're not within the debian
directory. This directory should not exist for avoiding conflicts as
the diff.gz of debian packages should contain a patch which creates
all required files. If e.g. both upstream and Debian packagers modify
the package and thus the changelog, it's likely there will be actual
conflicts. So after all, do not touch packagers work and everything
will be fine ;-)

Toby


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: Debian Packaging

Israel-28
Hi,
sorry I have been busy lately and could not reply on github yet.

Debian is now actively maintaining this package... well actually I will be maintaining it in Debian as a part of the Debian Edu team which takes care of this package now.

So there is no need for us to include the Debian stuff any longer.  However, as Toby and Tres are describing we still should generate some of the information.  The generation of the man page and desktop file should be controlled by the LMMS team.  But, most of the Debian specifics like the control file, install files, etc.. should be left the the packagers.

The entire issue was that no one could reach the Debian package maintainer for a very long time.  I did get in touch once and they did get up to version 1.0.0 after staying with 0.4.10 for a very long time.  Now we can directly influence the Debian package (and also then Ubuntu, Mint and the many other distros using Debian/Ubuntu repositories)

On 09/23/2015 01:33 PM, Tres Finocchiaro wrote:
Toby,

Thanks kindly.  I think the scenario that you are describing is correct... In some areas Israel was explicitly creating `/build/debian/` and placing files there, e.g:

Israel,

I'm not sure how manual the packaging process is for you today, but I strongly advise to take as much information from our build process as possible to be fed into the Debian packaging process.

At a glance it appears a lot of it should be removed, but if this leaves you maintaining a list of authors, homepage, project name, project description, you may decide to find a place to configure this information that can easily be picked up by the build process.

The good news is that removing the `cmake/debian` stuff makes the open PR much easier for us to merge since there are much less changes to be approved.  I'll put a few final comments on it now so that we can get this stuff integrated.

-Tres




On Wed, Sep 23, 2015 at 9:40 AM, Tobias Doerffel <[hidden email]> wrote:
Hi,

helper scripts are no problem as long as they're not within the debian
directory. This directory should not exist for avoiding conflicts as
the diff.gz of debian packages should contain a patch which creates
all required files. If e.g. both upstream and Debian packagers modify
the package and thus the changelog, it's likely there will be actual
conflicts. So after all, do not touch packagers work and everything
will be fine ;-)

Toby



-- 
Regards

------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel