contrib and it's dependencies with other repos
Hi. This topic sometimes looks hot but is not considered a major issue and nobody has a strong opinion if (and how) it can be solved. Please, follow up with suggestions. I guess you are familiar with current contrib rules [1]. The problem: an average CRUX contributor can't just put a port depending on something from gnome/kde/xfce (DE) into contrib, nor can he put it into the specific DE repository. It makes many ports hard to find/update/trust. Some ports will die inside private repos, as not many users like to subscribe to those (and play with prt-get.conf to build their personal dependency strategy). While I admit CRUX is DIY distro without a strict policy for everything... the status and possible usage scenarios (tips) of DE repositories looks unintuitive. Another aspect is a so called 'port duplication' issue. In general, it might be not fatal to have ports with different options in different repos. One will just have to put his favourite DE on the top of prt-get.conf/prtdir statements. It might work in most cases, but we have to be aware of the potential problems in each specific case. Few possible ways to go: Pretend that DE repos are just a part of contrib (and modify rules). cons: - DE maintainers might not like generic contrib rules or just to be a part of it; Give contrib members the power to submit ports to DE repos (insist on cooperation). cons: - not everyone even use those DE (subscribing to everything is an overkill); - DE maintainers will be against; Make a contrib-gnome, contrib-xfce, contrib-kde repos and submit DE specific contrib ports there, adjust rules. cons: - makes things too complicated; Port duplication (at least with opt) seems hard to overcame in any case. It could be possible to clean up contrib and DE repos of the ports that are in opt to some extent. [1] http://crux.nu/Main/ContribRules -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta
This topic sometimes looks hot but is not considered a major issue and nobody has a strong opinion if (and how) it can be solved. Please, follow up with suggestions.
Yes, I don't think its a mayor issue. I don't know about gnome or xfce, but so long I've been asked only once to include a port into the kde repo that used to be in contrib.
Make a contrib-gnome, contrib-xfce, contrib-kde repos and submit DE specific contrib ports there, adjust rules. cons: - makes things too complicated;
I think this would be by far the best solution. It would keep everybody happy, and people don't have to subscribe to DE specific contrib ports if they just want their basic DE. I don't see why it has to be more complicated than contrib itself, the rules should be pretty much the same, and whenever someone is given access to contrib he should also be given access to contrib-* (no need to apply to different contrib repos separately). -- Alan
Alan Mizrahi wrote:
Make a contrib-gnome, contrib-xfce, contrib-kde repos and submit DE specific contrib ports there, adjust rules. cons: - makes things too complicated;
I think this would be by far the best solution. It would keep everybody happy, and people don't have to subscribe to DE specific contrib ports if they just want their basic DE.
I don't see why it has to be more complicated than contrib itself, the rules should be pretty much the same, and whenever someone is given access to contrib he should also be given access to contrib-* (no need to apply to different contrib repos separately).
I think it gets too complicated from that point, creating gadzilion of repositories isn't good solution. If DE maintainers are afraid of allowing contrib members to access their repos, I think good solution would be changing contrib rules so we could maintain specific DE dependent ports in contrib. Regards Bartek
Hello, Alan. On Mon, 28 Jul 2008 10:07:25 -0430 Alan Mizrahi <alan+crux@mizrahi.com.ve> wrote:
This topic sometimes looks hot but is not considered a major issue and nobody has a strong opinion if (and how) it can be solved. Please, follow up with suggestions.
Yes, I don't think its a mayor issue. I don't know about gnome or xfce, but so long I've been asked only once to include a port into the kde repo that used to be in contrib.
Ok, say someone have a digikam port in a personal repo. The list of ports he has to maintain is: digikam, kipi-plugins, libkipi, libkexiv2, libkexif, libkdcraw, jasper. There are more deps found in opt, contrib and (obviously) kde repos. It can't be put in contrib. It is just to much to ask kde maintainer to take it over and test each version upgrade (and it still has deps from contrib). The maintainer is doomed to keep it private forever.
Make a contrib-gnome, contrib-xfce, contrib-kde repos and submit DE specific contrib ports there, adjust rules. cons: - makes things too complicated;
I think this would be by far the best solution. It would keep everybody happy, and people don't have to subscribe to DE specific contrib ports if they just want their basic DE.
I don't see why it has to be more complicated than contrib itself, the rules should be pretty much the same, and whenever someone is given access to contrib he should also be given access to contrib-* (no need to apply to different contrib repos separately).
Not the worst case, but this requires some sort of cooperation with DE maintainers. "Please add this and that option" or "give me that port, I'll maintain it in contrib-foo as it is essential for the app bar". -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta
Hi, On Mon, Jul 28, 2008 at 10:43:50 +0300, Mikhail Kolesnik wrote:
Hi. [...] The problem: an average CRUX contributor can't just put a port depending on something from gnome/kde/xfce (DE) into contrib, nor can he put it into the specific DE repository.
It makes many ports hard to find/update/trust. Some ports will die inside private repos, as not many users like to subscribe to those (and play with prt-get.conf to build their personal dependency strategy).
While I admit CRUX is DIY distro without a strict policy for everything... the status and possible usage scenarios (tips) of DE repositories looks unintuitive. I'm not using any of the three DE's with a dedicated repository, so I may not know the typical problems here, plus to me there are some questions (see below) which make it hard to judge the different variants.
That said, if I'm looking for a KDE specific app, and there's a dedicated KDE repository, I'd expect it to be there. I'm not sure if any other solution can be considered more intuitive.
Give contrib members the power to submit ports to DE repos (insist on cooperation). cons: - not everyone even use those DE (subscribing to everything is an overkill); Not everyone uses contrib either. So if a user is using KDE and the KDE repository, subscribing to contrib for that single KDE app she wants from contrib would be overkill as well.
- DE maintainers will be against; Is that really the case?
I have two more questions for DE maintainers which IMO have a major impact on the decision making: a) do you require your repository to be listed before 'opt'? b) do you depend on ports from contrib? Looking forward to reading your comments! Best wishes, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Hello, Johannes. On Mon, 28 Jul 2008 17:44:34 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
[...] I'm not using any of the three DE's with a dedicated repository, so I may not know the typical problems here, plus to me there are some questions (see below) which make it hard to judge the different variants.
In fact I have all three repos listed in prt-get.conf but can hardly remember any significant (technical) problems I've run into. I guess there are some, which I am not aware off as I am not directly running those integrated desktop environments. It's more about hating to maintain nice stuff in a personal repository. And I am more concerned about the a) and b) kind of questions you've spotted.
[...] - not everyone even use those DE (subscribing to everything is an overkill); Not everyone uses contrib either. So if a user is using KDE and the KDE repository, subscribing to contrib for that single KDE app she wants from contrib would be overkill as well.
I guess it is a very rear case to see someone subscribed to a big descktop environment repo and not subscribed to the contrib.
- DE maintainers will be against; Is that really the case?
I have two more questions for DE maintainers which IMO have a major impact on the decision making: a) do you require your repository to be listed before 'opt'? b) do you depend on ports from contrib?
That is the questions! I'd like to see if the answers are common between three major repositories here. -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta
Hi, Johannes Winkelmann wrote:
Hi,
On Mon, Jul 28, 2008 at 10:43:50 +0300, Mikhail Kolesnik wrote:
Hi. [...] The problem: an average CRUX contributor can't just put a port depending on something from gnome/kde/xfce (DE) into contrib, nor can he put it into the specific DE repository.
It makes many ports hard to find/update/trust. Some ports will die inside private repos, as not many users like to subscribe to those (and play with prt-get.conf to build their personal dependency strategy).
While I admit CRUX is DIY distro without a strict policy for everything... the status and possible usage scenarios (tips) of DE repositories looks unintuitive. I'm not using any of the three DE's with a dedicated repository, so I may not know the typical problems here, plus to me there are some questions (see below) which make it hard to judge the different variants.
That said, if I'm looking for a KDE specific app, and there's a dedicated KDE repository, I'd expect it to be there. I'm not sure if any other solution can be considered more intuitive.
Give contrib members the power to submit ports to DE repos (insist on cooperation). cons: - not everyone even use those DE (subscribing to everything is an overkill); Not everyone uses contrib either. So if a user is using KDE and the KDE repository, subscribing to contrib for that single KDE app she wants from contrib would be overkill as well.
Maybe would be useful to have a uniq-port-sync-tool
- DE maintainers will be against; Is that really the case?
I have two more questions for DE maintainers which IMO have a major impact on the decision making: a) do you require your repository to be listed before 'opt'? b) do you depend on ports from contrib?
Well, I'm the xfce maintainer, and for what I known I should provide all dependencies which are not listed on core, opt and xorg collections yet. So xfce don't depends on opt or contrib. But for example the xfce terminal depends on 'vte' which is not listed on core/opt/xorg, but its provided by gnome and that implies that I had to duplicated it. Due to that, some collections have to accept duplicates or should exist an extra DE_share_repo for avoiding dups (maybe opt, xorg, xopt, x ?). I also proposed sometimes the repo_depencies concept: (source fragment of 'repoverify') [1] [...] core) REPO_DEPS="core" ;; opt) REPO_DEPS="core opt xorg" ;; xorg) REPO_DEPS="core opt xorg" ;; contrib) REPO_DEPS="core opt xorg contrib" ;; gnome) REPO_DEPS="core opt xorg gnome" ;; kde) REPO_DEPS="core opt xorg kde" ;; xfce) REPO_DEPS="core opt xorg xfce" ;; e17) REPO_DEPS="core opt xorg e17" ;; [...] Best regards, Jose V Beneyto [1]. http://mikeux.dyndns.org/crux/ports/crux-repo-utils/
On Mon, Jul 28, 2008 at 08:53:47PM +0200, Jose V Beneyto wrote:
I have two more questions for DE maintainers which IMO have a major impact on the decision making:
I'll answer these questions as the former maintainer of xfce, hope this is ok for you, Jose.
a) do you require your repository to be listed before 'opt'?
No.
b) do you depend on ports from contrib?
No.
Well, I'm the xfce maintainer, and for what I known I should provide all dependencies which are not listed on core, opt and xorg collections yet. So xfce don't depends on opt or contrib. But for example the xfce terminal depends on 'vte' which is not listed on core/opt/xorg, but its provided by gnome and that implies that I had to duplicated it.
In that special case, vte, the most obvious solution would be to put it into opt, so xfce and gnome can use it from there. Nowadays even gnome uses nearly the same configure options, IIRC that wasn't so in the past when I have created the xfce repo.
Due to that, some collections have to accept duplicates or should exist an extra DE_share_repo for avoiding dups (maybe opt, xorg, xopt, x ?).
IMO it's not principally a bad thing to have duplicates, for example look at the deps of xfce/librsvg and gnome/librsvg to see what I mean. best regards Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
[...]
a) do you require your repository to be listed before 'opt'?
No, because I have duplicated qt3 into the kde repository. Simone once asked me to keep that port in the kde repo because he was going to drop it from opt, but I guess he forgot to do it. Right now there is an outdated version of qt3 in opt and the latest version in kde, so having opt before kde would give you the old version. There is also a problem in the opt evrsion that prevents some qt apps from building, I just tried to build twinkle (from contrib) using qt3 from opt and it failed. Since there are some apps in contrib and opt depending on qt3, I think this port should be in opt and not in the kde repo. Simone, what do you think? If you still want to give up qt3, I could maintain it.
b) do you depend on ports from contrib?
No. -- Alan
Alan wrote:
[...]
a) do you require your repository to be listed before 'opt'?
No, because I have duplicated qt3 into the kde repository. Simone once asked me to keep that port in the kde repo because he was going to drop it from opt, but I guess he forgot to do it.
Right now there is an outdated version of qt3 in opt and the latest version in kde, so having opt before kde would give you the old version.
There is also a problem in the opt evrsion that prevents some qt apps from building, I just tried to build twinkle (from contrib) using qt3 from opt and it failed.
Since there are some apps in contrib and opt depending on qt3, I think this port should be in opt and not in the kde repo.
Simone, what do you think? If you still want to give up qt3, I could maintain it.
b) do you depend on ports from contrib?
No.
Well, after using repoverify script on kde repo I get some ports with missing dependencies. Also I added the result given by the portdb for these ports: kde/kdelibs: libidn (contrib) kde/kdelibs: imlib (contrib) imlib (romster) kde/kdelibs: gpgme (contrib) kde/kdelibs: gamin (gnome) gamin (hnc) gamin (ticklestix) kde/kaffeine: xine-lib (contrib) xine-lib (han) kde/kdebluetooth: bluez (NOT FOUND) kde/kdebluetooth: openobex (alan) openobex (nexscrp) openobex (ticklestix) openobex (yhafri) kde/kmobiletools: bluez (NOT FOUND) kde/kmobiletools openobex (alan) openobex (nexscrp) openobex (ticklestix) openobex (yhafri) kde/amarok: taglib (contrib) kde/ksquirrel: opengl (NOT FOUND) kde/qt3: x11 (han) kde/kdeartwork: xscreensaver (contrib) xscreensaver (jdolan) xscreensaver (predatorfreak) xscreensaver (yhafri) kde/kdeadmin: lm_sensors (contrib) lm_sensors (mike) lm_sensors (xfce) kde/kdegraphics: fribidi (han) fribidi (hnc) fribidi (romster) kde/kdepim: pilot-link (aba) pilot-link (diederick) kde/kdepim: pinentry-qt (NOT FOUND) kde/kdemultimedia: xine-lib (contrib) xine-lib (han) kde/kdemultimedia: libtunepimp (hnc) libtunepimp (romster) kde/kdemultimedia: taglib (contrib) Best regards, Jose V Beneyto
[...]
Well, after using repoverify script on kde repo I get some ports with missing dependencies. Also I added the result given by the portdb for these ports:
Thanks for pointing it out. So for the time being kde uses some ports in contrib, but I believe that most of these ports should be in opt, for example libidn, gamin, bluez, etc. -- Alan
Hi, On Mon, Jul 28, 2008 at 17:44:34 +0200, Johannes Winkelmann wrote:
Hi,
On Mon, Jul 28, 2008 at 10:43:50 +0300, Mikhail Kolesnik wrote:
Hi. [...] The problem: an average CRUX contributor can't just put a port depending on something from gnome/kde/xfce (DE) into contrib, nor can he put it into the specific DE repository.
It makes many ports hard to find/update/trust. Some ports will die inside private repos, as not many users like to subscribe to those (and play with prt-get.conf to build their personal dependency strategy).
While I admit CRUX is DIY distro without a strict policy for everything... the status and possible usage scenarios (tips) of DE repositories looks unintuitive. I'm not using any of the three DE's with a dedicated repository, so I may not know the typical problems here, plus to me there are some questions (see below) which make it hard to judge the different variants.
That said, if I'm looking for a KDE specific app, and there's a dedicated KDE repository, I'd expect it to be there. I'm not sure if any other solution can be considered more intuitive.
Just adding some notes here, following up a discussion from IRC: Here's a rather radical idea: what would happen if we merged the collections on the client side, i.e. opt+xorg+xfce (all committer to xorg and xfce also have commit access to opt) would be merged together, and contrib+gnome (+kde if Alan joined contrib). Of course, other combinations are possible too (i.e. all the three together with opt, or all the three with contrib). Remember that in the past, we had all of it in opt too, and I couldn't remember any complaints about this. This would mean the following: - dependency situation is clear: contrib can depend on all ports that are in the "contrib meta collection" - repositories can still be developed independently - intuitive to the user: low numbers of repositories At the same time, there's an obvious drawback: the user would have to sync all more repositories which she potentially doesn't need. I believe this is only a psychological problem, since users of source based distributions are expected to have both enough bandwidth and diskspace anyway. However we could offer a way for those users that care to disable the repositories (opt-out), i.e. those that are worried about bandwidth could disable the repos they don't want, but will have to expect missing dependencies. Just adding this here as an idea so that others can comment, I haven't really had the time to think it fully through and I'm _not_ proposing this as _the_ solution but just as one possibility that could also be evaluated. Finally, note that there's the same problem we had with the former contrib setup: there may be duplicate ports, and they will have to be dealt with. Regards Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Mon, Jul 28, 2008 at 10:43:50AM +0300, Mikhail Kolesnik wrote:
Hi.
This topic sometimes looks hot but is not considered a major issue and nobody has a strong opinion if (and how) it can be solved. Please, follow up with suggestions.
I guess you are familiar with current contrib rules [1].
The problem: an average CRUX contributor can't just put a port depending on something from gnome/kde/xfce (DE) into contrib, nor can he put it into the specific DE repository.
A obvious solution is to move the DE repos into contrib. Sure, we have either find a unified version of some ports that are now dups in the different repos, or, if not possible or sensible, accept different ports of the same program. E.g. something like librsvg-gnome and librsvg instead of having gnome/librsvg and xfce/librsvg. Sure, to get this working without troubles a little bit more communication is necessary, which isn't a bad thing IMO. Greetings Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
Hey, On Sat, Aug 09, 2008 at 15:11:35 +0200, Juergen Daubert wrote: [...]
A obvious solution is to move the DE repos into contrib.
I'd actually welcome this too. Earlier, we had both KDE and GNOME in opt, and I can't remember any real issues.
Sure, to get this working without troubles a little bit more communication is necessary, which isn't a bad thing IMO. Agreed.
A slightly less radical approach could be to have separate repostories as we have now, which are all part of the "contrib" projects, like this: contrib project: - "main" repository (current 'contrib') - "gnome" repository (current 'gnome') - "kde" repository (current 'kde') - "xfce" repository (current 'xfce') Contrib members would get access to all four repositories, and could thus commit specific ports to the DE repos. At the same time, all DE repositories would implicitely depend on the contrib/main repository, thus common ports which are currently in multiple repositories would be put into contrib/main. We could consider changing the syntax of /etc/ports/contrib.rsync a bit, to allow specifying the subrepositories there. Given that we've not been very good to come to a conclusion here, I'd suggest we discuss this at the next IRC meeting. Cheers, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
participants (7)
-
Alan -
Alan Mizrahi
-
Bartek Palmowski -
Johannes Winkelmann -
Jose V Beneyto -
Juergen Daubert -
Mikhail Kolesnik