On Fri, Apr 1, 2011 at 12:25 AM, Károly Pados <pkaroly@...> wrote: > I created a basic gtk3 package in AUR, though later I noticed that there is > a gnome-unstable repository, with gtk3 in it. Please delete my gtk3 package > in AUR, I don't want it to start conflicting with gnome-unstable things and Removed. :)
Am 31.03.2011 21:21, schrieb Aaron DeVore: > I started maintaining some Python 2 packages that currently use the > python- prefix, but need to be renamed to use python2-. Python 3 > versions will soon come out, so I don't want people using the python-* > package until then. I want to still have the packages in the AUR so > that someone doesn't accidentally recreate the python-* package. How > do I make sure that people don't use the python-* packages until it's > appropriate? > > -Aaron DeVore > I'd say leave a comment on the AUR pages like "Do not use this package, use python2-foo instead." Then upload your new python2-packages under. If there are too many packages you maintain the task is maybe scriptable. Regards Stefan
On 2011/3/31 Oon-Ee Ng <ngoonee.talk@...> wrote: > I agree with the concept. However, in your opinion does > nvidia-beta-all fall under non-reproducible? It does different things > on different machines, but entirely in a non-interactive way. In case > you don't want to bother to take a look at the PKGBUILD (I wouldn't), > here's the basic thing it does:- > > 1. grep through files in /boot/ to find installed kernels > 2. compile the NVIDIA driver for those kernels > > It cannot be compiled in a chroot (unless the requisite kernels are > available), but it seems to satisfy the rest of your criteria. My definition was not about interactivity but dynamic nature. nvidia-beta-all is dynamic in the sense that it *computes* local variables that influence the resulting package. A reproducible package does as much as it can to hardcode the parameters and options it uses so that each time it is compiled it must produce the same results (this is usually false, because sonames may change and installed package may influence configuration steps). In other words, I think PKGBUILDs that could be incorportaed in a binary repository as is should not be removed in favour of a PKGBUILD that cannot be used for a binary repository: nvidia-beta-all can't be used for a repository because it can produce totally different packages with the same name, version and pkgrel. It is however a convenient thing to have. By the way, I think you should tweak your PKGBUILD so that it correctly sets its $depends array. I don't think nvidia packages(Continue reading)
Thanks for your response Rémy, On Fri, Apr 1, 2011 at 7:54 AM, Rémy Oudompheng <remyoudompheng@...> wrote: > My definition was not about interactivity but dynamic nature. > nvidia-beta-all is dynamic in the sense that it *computes* local > variables that influence the resulting package. A reproducible package > does as much as it can to hardcode the parameters and options it uses > so that each time it is compiled it must produce the same results > (this is usually false, because sonames may change and installed > package may influence configuration steps). > > In other words, I think PKGBUILDs that could be incorportaed in a > binary repository as is should not be removed in favour of a PKGBUILD > that cannot be used for a binary repository: nvidia-beta-all can't be > used for a repository because it can produce totally different > packages with the same name, version and pkgrel. It is however a > convenient thing to have. Fair enough. > > By the way, I think you should tweak your PKGBUILD so that it > correctly sets its $depends array. I don't think nvidia packages > really depend on their associated kernels (I mean you can remove the > kernels without removing the modules) but it prevents it from being > used as is by people who only have kernel26-lts, for example. > Change made, thanks. Original copied from nvidia-beta, I'll inform the maintainer that that should be removed. Only seems obvious once someone has pointed it out (to me) =)(Continue reading)
I've seen (in the past) various packages on the AUR which jumped by 3 or 4 pkgrels in a very short period of time. Sometimes it happens like this:- 1. Maintainer changes something and breaks the package with pkgrel=2 2. Bug reported on comments. Maintainer reverts change and makes pkgrel=3 It can also happen like this:- 1. Maintainer makes changes to pkgdesc or cleans up some of the commands, depends, etc. sets pkgrel=2 For both of the cases above, is pkgrel updating really necessary? For the second one, I think not, as changing documentation doesn't (shouldn't) require recompilation of the package by its users. Similarly if depends changes, users who already have the package installed would already have the dep, so no reason for such users to upgrade? For the first case its a bit more tricky. My reasoning is that if the PKGBUILD breaks and can't be built at all, the maintainer could simply release with the same pkgrel. Noone would have been able to build pkgrel=2 in that example anyway, so why jump to pkgrel=3? The reason I bring this up is because there's no easy way (yet) to diff what's changed between versions of the package, and hence when I notice a pkgrel change I can't really check to see what has been changed and whether its worth recompiling the package (for larger packages like firefox4 this can be significant).(Continue reading)
On Fri, Apr 01, 2011 at 08:12:42AM +0800, Oon-Ee Ng wrote: > I've seen (in the past) various packages on the AUR which jumped by 3 > or 4 pkgrels in a very short period of time. Sometimes it happens like > this:- > > 1. Maintainer changes something and breaks the package with pkgrel=2 > 2. Bug reported on comments. Maintainer reverts change and makes pkgrel=3 > > It can also happen like this:- > > 1. Maintainer makes changes to pkgdesc or cleans up some of the > commands, depends, etc. sets pkgrel=2 > > For both of the cases above, is pkgrel updating really necessary? For > the second one, I think not, as changing documentation doesn't > (shouldn't) require recompilation of the package by its users. > Similarly if depends changes, users who already have the package > installed would already have the dep, so no reason for such users to > upgrade? > > For the first case its a bit more tricky. My reasoning is that if the > PKGBUILD breaks and can't be built at all, the maintainer could simply > release with the same pkgrel. Noone would have been able to build > pkgrel=2 in that example anyway, so why jump to pkgrel=3? > > The reason I bring this up is because there's no easy way (yet) to > diff what's changed between versions of the package, and hence when I > notice a pkgrel change I can't really check to see what has been > changed and whether its worth recompiling the package (for larger > packages like firefox4 this can be significant).(Continue reading)
Am Fri, 1 Apr 2011 08:12:42 +0800 schrieb Oon-Ee Ng <ngoonee.talk@...>: > I've seen (in the past) various packages on the AUR which jumped by 3 > or 4 pkgrels in a very short period of time. Sometimes it happens like > this:- > > 1. Maintainer changes something and breaks the package with pkgrel=2 > 2. Bug reported on comments. Maintainer reverts change and makes > pkgrel=3 > > It can also happen like this:- > > 1. Maintainer makes changes to pkgdesc or cleans up some of the > commands, depends, etc. sets pkgrel=2 > > For both of the cases above, is pkgrel updating really necessary? For > the second one, I think not, as changing documentation doesn't > (shouldn't) require recompilation of the package by its users. > Similarly if depends changes, users who already have the package > installed would already have the dep, so no reason for such users to > upgrade? > > For the first case its a bit more tricky. My reasoning is that if the > PKGBUILD breaks and can't be built at all, the maintainer could simply > release with the same pkgrel. Noone would have been able to build > pkgrel=2 in that example anyway, so why jump to pkgrel=3? > > The reason I bring this up is because there's no easy way (yet) to > diff what's changed between versions of the package, and hence when I(Continue reading)
On Fri, Apr 1, 2011 at 4:11 AM, Alex Griffin <griffin.aj@...> wrote: > I submitted the package this morning but regretted it almost > immediately. It does not meet the submission guidelines (doesn't > download/verify) and my spacechem-demo PKGBUILD can also be used for > the purchased full game anyway. Removed, thanks!
RSS Feed294 | |
|---|---|
472 | |
625 | |
349 | |
396 | |
302 | |
412 | |
371 | |
287 | |
373 | |
301 | |
362 | |
352 | |
390 | |
495 | |
326 | |
260 | |
442 | |
426 | |
376 | |
347 | |
336 | |
279 | |
264 | |
238 | |
254 | |
368 | |
489 | |
569 | |
709 | |
481 | |
458 | |
649 | |
686 | |
330 | |
368 | |
230 | |
254 | |
272 | |
361 | |
198 | |
258 | |
405 | |
357 | |
311 | |
318 | |
506 | |
505 | |
288 | |
527 | |
329 | |
246 | |
260 | |
457 | |
234 | |
286 | |
227 | |
266 | |
187 | |
200 | |
324 | |
155 | |
214 | |
184 | |
462 | |
168 | |
182 | |
185 | |
260 | |
62 | |
191 | |
156 | |
534 | |
233 | |
307 | |
340 | |
67 | |
94 | |
189 | |
130 | |
114 | |
200 | |
65 | |
134 | |
246 | |
92 | |
117 | |
103 | |
77 | |
46 | |
109 | |
48 | |
173 | |
233 | |
293 | |
291 | |
91 | |
108 | |
70 | |
75 | |
50 | |
49 | |
116 | |
83 | |
48 | |
66 | |
34 | |
7 | |
38 |
