Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2012-10

Build-Depands: imagemagick

6 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Bernd

I found this in debian/control. Which part of Lazarus depends on imagemagick during building of Lazarus?

Also please could this entire debian directry please be removed entirely? It really make packaging much more complicated. Original upstream sources should not contain any debian packaging data, the package maintainer will maintain and provide this directory on his own and patch it into the original sources during packaging, this way also the debian changes diff (changes between orig.tar.gz and deb package) becomes much more clear and meaningful.

Reply by email

Vincent Snijders
to Bernd

2012/10/8 Bernd :

I found this in debian/control. Which part of Lazarus depends on imagemagick during building of Lazarus?

I think for creating images for the desktop shortcuts.

Show quoted text 8 lines
Also please could this entire debian directry please be removed entirely? It really make packaging much more complicated. Original upstream sources should not contain any debian packaging data, the package maintainer will maintain and provide this directory on his own and patch it into the original sources during packaging, this way also the debian changes diff (changes between orig.tar.gz and deb package) becomes much more clear and meaningful.

What is the debian maintainer is a Lazarus developer that wants his changes as close to the source as possible? So he maintains it here.

And it would mean I cannot create the snapshots anymore ...

Vincent

Reply by email

Mattias Gaertner
to Vincent Snijders
Show quoted text 5 lines
2012/10/8 Bernd : > I found this in debian/control. Which part of Lazarus depends on > imagemagick during building of Lazarus? I think for creating images for the desktop shortcuts.

In debian/rules the 48x48 icon is downsized to 32x32. The sf debian packages simply install the 128x128 icon, which is needed by nowadays desktops.

So, maybe the debian/rules file should be adapted.

[...]

Mattias

Reply by email

Bernd
to Mattias Gaertner

2012/10/8 Mattias Gaertner :

Show quoted text 5 lines
In debian/rules the 48x48 icon is downsized to 32x32. The sf debian packages simply install the 128x128 icon, which is needed by nowadays desktops. So, maybe the debian/rules file should be adapted.

I believe much of the stuff in debian/rules should go into the Makefile itself and be maintained there. Its not really easy to see which parts of this rues file exist only to satisfy debian policy and which part exist simply as a complete *replacement* of the original make install and which parts are outdated or not needed anymore. make install is used a lot of times by many people but debian/rules is used only once or twice per year and as soon as it has successfully built the package it is left alone again for another 6 months. This is why I think it should be *small*, only a *thin* wrapper around often used, well tested and maintained makefile targets, not a full blown alternative makefile on its own.

Reply by email

Mattias Gaertner
to Bernd

Bernd hat am 8. Oktober 2012 um 12:23 geschrieben:

Show quoted text 19 lines
2012/10/8 Mattias Gaertner : > In debian/rules the 48x48 icon is downsized to 32x32. > The sf debian packages simply install the 128x128 icon, which is > needed by nowadays desktops. > > So, maybe the debian/rules file should be adapted. I believe much of the stuff in debian/rules should go into the Makefile itself and be maintained there. Its not really easy to see which parts of this rues file exist only to satisfy debian policy and which part exist simply as a complete *replacement* of the original make install and which parts are outdated or not needed anymore. make install is used a lot of times by many people but debian/rules is used only once or twice per year and as soon as it has successfully built the package it is left alone again for another 6 months. This is why I think it should be *small*, only a *thin* wrapper around often used, well tested and maintained makefile targets, not a full blown alternative makefile on its own.

The Makefile is critical and therefore maintained by the Laz devels. The debian files are maintained and understood only by the debian package maintainers.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121008/fc5ff23d/attachment.html>

Reply by email

Bernd
to Mattias Gaertner

2012/10/8 Mattias Gaertner :

The Makefile is critical and therefore maintained by the Laz devels. The debian files are maintained and understood only by the debian package maintainers.

Thats why I said: remove it from lazarus sources entirely.

And encourage debian maintainers to give *feedback*, file bugs if they find that original make install does something incredibly stupid (for example not respecting $(DESTDIR) or doing a recursive cp -r . $(SOMEWHERE) that will fail if the $(SOMEWHERE) is a sub directory and similar things). Unfortunately debian maintainers have the habit of giving no feedback at all, not even asking how things are supposed to work and rather spend lot of time to write hundreds of lines of completely redundant *duplicate* makefile *from scratch* instead of just asking the original makefile authors to make it accept just one more variable.

Ideally the debian/rules file should just call the original make install which will then do a proper install suitable for most systems out of the box and then do only some minor adjustments to satisfy debian policy. They should not be forced or even encouraged to rewrite almost the entire makefile from scratch.

Reply by email