Cairo-xcb for awesome window manager

General talk about packaging procedures and packages.
Post Reply
User avatar
Tim CowChip
Posts: 301
Joined: 27. May 2011, 03:35
Location: Cascade Locks, OR

Cairo-xcb for awesome window manager

Post by Tim CowChip » 5. Aug 2012, 22:41

I followed the steps put forth on this site. and was able to get the awesome window manager running alongside my Salix 13.37 MATE installation.
I used SlackBuild to make the cairo package, so it is not useful for package submission as a Salix package ticket.

There was a comment made in the Hacker Public Radio interview with gapan and shador that some people (Peter64) might enjoy running awesome on Salix. I enjoy running awesome as well and found that it required cairo with xcb enabled.

From cairo.SlackBuild

Code: Select all

# None of these are 'stable' yet...
#  --enable-qt \
#  --enable-gl \
#  --enable-drm \
#  --enable-xcb \
#  --enable-xlib-xcb \
#  --enable-xcb-drm \
#  --enable-drm-xr \
# Skipping this, because it causes a dependency on the specific
# version of binutils installed at compile time:
#  --enable-trace
I don't know if --enable-xcb is now stable as the tutorial is over a year old or if anyone would be interested in allowing an alternative cairo package with xcb enabled to be included in the repositories, but I do know that it won't be that easy for new users to get awesome running on their Salix installation without it.

I am volunteering myself for the purpose of building such a package with slkbuild this time, and if accepted, for building the awesome window manager package later.

Feel free to discourage me from wasting my time if there is no interest in adding these packages or if anyone thinks they can do a better job of it, I won't be offended. Life is short and I'm not getting any younger.
ImageImage

Shador
Posts: 1295
Joined: 11. Jun 2009, 14:04
Location: Bavaria

Re: Cairo-xcb for awesome window manager

Post by Shador » 8. Aug 2012, 00:48

Tim CowChip wrote:I used SlackBuild to make the cairo package, so it is not useful for package submission as a Salix package ticket.
That's not the point. Although SLKBUILDs are favoured, SlackBuilds are not forbidden. Nobody said that anywhere in the bugtracker either.
Tim CowChip wrote:an alternative cairo package with xcb enabled to be included in the repositories
This is the big problem. We don't usually replace Slackware packages. Because Salix is meant to stay a Slackware system (+ additions) and not a completely new system. The latter is what you get with replacing packages. If we start with one package more than just that one package would follow and in the end it wouldn't be anymore Slackware. There are other reasons as well. Like possibly decreased stability and additional work for example. When forking a package there needs to be someone who builds the Salix version if Slackware releases a new package. And that Salix one shouldn't be built too late after Slackware released its new package.
I'm reluctant to provide a replacement cairo package. After all there would be two solutions a Salix cairo package with xcb enabled or a cairo-xcb package which is required by awesome and listed as conflicting with cairo. Anyway I just don't see what would make this change really special so the same reasoning can not be used for many other packages. Just xy requires feature/patch/change ab is not enough. There's for any package going to be such an xy.

I did not look closer at packaging awesome. But any chance there is a different solution to provide awesome without rebuilding other packages?

This might seem bureaucratic, conservative or whatever you want to call it. Actually I'm fairly sure it works perfectly for you and there's absolutely nothing wrong with your approach. But just because it works for you (and others) or even works in general doesn't make it necessarily a suitable solution for public deployment in our main repository. Any user using Salix is then affected by that change and can't just easily go back. A separate repository which users wanting awesome could add to their package manager could be another solution. Similar to what I did with the kernel package or others did with xfce, ... The advantage here is that the user willingly chooses that change by adding a non-default repository and could go back to the default Salix setup at any time or not leave it at all.


Any other thoughts?
Image

User avatar
Tim CowChip
Posts: 301
Joined: 27. May 2011, 03:35
Location: Cascade Locks, OR

Re: Cairo-xcb for awesome window manager

Post by Tim CowChip » 8. Aug 2012, 01:36

Tim CowChip wrote: an alternative cairo package with xcb enabled to be included in the repositories
I'm not sure I said this right, but what I meant was having cairo and cairo-xcb both available in the repo with vanilla cairo installed by default and the xcb-enabled version available to replace cairo if needed. Or to have the option to enable xcb when installing cairo with sourcery like enabling lua for conky.

Another way to get awesome running on Salix would be to build an Awesome version for installation as has been done with Ratpoison or Fluxbox. A seperate repository is another way that could work. That's the way openSUSE does it and launchpad is where Ubuntu users get non standard packaging.

I guess there needs to be some degree of interest before such an undertaking, which is what I meant by "feel free to talk me out of it"

EDIT

I don't think cairo-xcb so much conflicts with vanilla cairo as it just replaces cairo with an xcb-enabled version and otherwise is the same package. When I installed it, it didn't cause any problems with anything that depends on it.
ImageImage

Shador
Posts: 1295
Joined: 11. Jun 2009, 14:04
Location: Bavaria

Re: Cairo-xcb for awesome window manager

Post by Shador » 8. Aug 2012, 21:34

Tim CowChip wrote:I'm not sure I said this right, but what I meant was having cairo and cairo-xcb both available in the repo with vanilla cairo installed by default and the xcb-enabled version available to replace cairo if needed.
It doesn't really matter whether the package is named cairo-xcb or just cairo. Both solutions have quite similar problems except that cairo-xcb is not installed by default.
Some reading: https://bugzilla.redhat.com/show_bug.cgi?id=465759
The problem is either way we're providing a package with an experimental, unstable (, poorly maintained) feature enabled and making it the default for at least some users. So do we want to provide unstable software? After all as long as awesome is installed cairo-xcb is as well and even if awesome is not used any application could be affected by problems with cairo-xcb. Their also talking about possible ABI changes with xcb-enabled cairo there. That's an absolute no no. If Slackware were to upgrade cairo then cairo-xcb would need an upgrade as well. If xcb causes an ABI change, the library is unusable with all applications linked to cairo and any such package would need an xcb version.
Tim CowChip wrote:Another way to get awesome running on Salix would be to build an Awesome version for installation as has been done with Ratpoison or Fluxbox.
That doesn't solve anything. Quite the opposite one only can start working on a new edition when all the necessary packages are already in the repository. What's the purpose of building a new edition when the packages are not yet n the repository i.e. not available?
Tim CowChip wrote:I don't think cairo-xcb so much conflicts with vanilla cairo as it just replaces cairo with an xcb-enabled version and otherwise is the same package. When I installed it, it didn't cause any problems with anything that depends on it.
Yes, it does. It installs files in the same location which are not the same. Therefor a conflict exists. If you install cairo first and cairo-xcb next you get the cairo with xcb files. When there's an upgrade for cairo but not yet cairo-xcb, the cairo package is reinstalled and thus you now have cairo without xcb.
Solution: Don't have both packages installed at the same time.
Meaning of conflict: The packages listed in the .con file must not be installed while this package is installed. (I.e. cairo must not be installed when cairo-xcb is installed).
Tim CowChip wrote:I guess there needs to be some degree of interest before such an undertaking, which is what I meant by "feel free to talk me out of it"
That's not the point. I'm just telling you that there are some maybe not so obvious important problems, that must be overcome before going ahead.
Image

User avatar
Tim CowChip
Posts: 301
Joined: 27. May 2011, 03:35
Location: Cascade Locks, OR

Re: Cairo-xcb for awesome window manager

Post by Tim CowChip » 8. Aug 2012, 21:53

Ok then, thanks for the information. And now I am no longer interested in using awesome. There's always i3 and scrotwm if you like tiling window managers.

Not to fork this thread, but a general question about building packages since I'm in the right forum for it.

I am running Salix64-XFCE-13.37 with kernel-huge 2.6.37.6-x86_64-2 and Salix64-MATE-13.37 with your kernel-huge-recent-3.3.6-x86_64-1ab on another computer. All else being equal will there be any difference in packages built on the 2 machines?

EDIT

I have a feeling that the answer to this question will be something like "it depends on which package".
And as I have upgraded Salix64-XFCE-13.37 to Salix64-XFCE-current it is no longer a valid question.

So, never mind.
ImageImage

Shador
Posts: 1295
Joined: 11. Jun 2009, 14:04
Location: Bavaria

Re: Cairo-xcb for awesome window manager

Post by Shador » 9. Aug 2012, 20:35

You should highly favour building packages on a clean system. That's because production systems are always polluted in the one or other manner or get so with time. Not so much because of the machine more because of us. :D
Some possible solutions are chroots, virtual machines (virtualbox, qemu, ...) or second installations. Optimally they're combined with some sort of snapshotting. This means you setup a base system which you keep up-to-date. When building a package you only install the necessary packages, do the build (and the testing). Afterwards you return back to your unmodified base system. Therefor every package is built on a fresh and clean system.

I'm starting to use the chroot approach and combine it with the snapshotting capabilities of btrfs. To optimize the workflow I wrote a tool called pad: http://www.salixos.org/forum/viewtopic.php?f=22&t=3374
One should note that with chroots (as with second installations) you're limited to the architectures your processor can run unless possibly did some magic with qemu. While that's at one hand the advantage (you get native speed unlike with virtual machines), it can also be a disadavantage for the aforementioned reason. Anyway if you've got a 64-Bit processor and are running a 64-Bit kernel, you can build packages for 32- and 64-Bit which is all you need with Salix.

In the end we can't do more than highly recommending this. We have no way to check how you're building packages and there's nothing bad about not using separate packaging systems. Other installations can be as clean as a separate one and even if they aren't the resulting package is not necessarily affected. But it's a pretty sensible measure.


As far as awesome is concerned. Probably the best approach for people who really want awesome is a user repository. You can pretty much do anything you want there. Of course you should try to ensure quality and compatibility. If done properly it's not that bad at all.

These are the current possible "solutions" for the Salix repository.
With a cairo package we would unleash possibly unstable software on all Salix users.

With a cairo-xcb package we would end up in dependency hell. One package could requie cairo the other one cairo-xcb but they should not be installed at the same time. After all most packages require cairo, one would need to change their dependencies to also allow cairo-xcb which is was too uncertain and especially to big a change.

A new idea: A cairo-xcb package which installs its file to a different location than the cairo package (awesome would be told to use the files from there everything else the default cairo ones) thus preventing the conflict. This is not really clean either. But it circumvents the two previous big problems at least.
Image

User avatar
JRD
Salix Warrior
Posts: 949
Joined: 7. Jun 2009, 22:52
Location: Lyon, France

Re: Cairo-xcb for awesome window manager

Post by JRD » 10. Aug 2012, 08:11

About your last idea, then call it cairo-awsome, if it's for use only by awsome :) And the idea to install it in not default localtion, and building awsome with it is I think, a good solution.
Image

User avatar
gapan
Salix Wizard
Posts: 5519
Joined: 6. Jun 2009, 17:40

Re: Cairo-xcb for awesome window manager

Post by gapan » 10. Aug 2012, 08:16

Other ways to do it properly:

1. Bundle this cairo-xcb inside the awesome package. Nothing else requires it after all. It will still have to be in a non-default location.
2. Build cairo-xcb static and compile awesome static with that. No external dependencies this way. This might require building other stuff static too.
Image
Image

User avatar
Tim CowChip
Posts: 301
Joined: 27. May 2011, 03:35
Location: Cascade Locks, OR

Re: Cairo-xcb for awesome window manager

Post by Tim CowChip » 10. Aug 2012, 17:03

This Linux Questions thread was referenced in the turtorial and talks about upgrading xcb-util0.3.6 to xcb-util-0.3.8 and installing xcb-icccm>=0.3.8 (which is now provided by xcb-util-wm). I tried using xcb-util-wm-0.3.9, but it didn't work xcb-util-wm-0.3.8 did work. I guess it would need to be bundled as well.
ImageImage

Post Reply