advice on user guidelines

slide_rule · 2008-06-11 13:45:59

I posted yesterday about the bochs package I uploaded, and got asked by Dragonlord to take it down since it already exists in the [extra] repo. I pulled the package, but I wanted an opinion from the AUR community about how to proceed.

The official [extra] bochs package is compiled without x86-64 emulation support, and without the internal debugger enabled. This is fine if you're emulating an existing OS, but doing os development really needs that debugger. Moreover, compiling bochs with the debugger enabled and >= gcc.4.3 results in a failed build because of C++ namespace issues. I found a patch that fixes this behavior and included it in the package tarball. This required some debugging and searching, so I wanted to share the work I had done so others didn't have to duplicate it.

Since bochs sets many options at compile time, package maintainers have to figure out what the best defaults are, and IMHO the Arch maintainers have done just that, so I didn't want to file a bug report or force everyone who installs bochs to deal with the 64bit emulation and the internal debugger, so I thought I'd create a package offshoot.

Like I said, I do want to follow the AUR guidelines, so I took down the package, but I thought it was worth discussing. Hopefully I'm not coming across as whining about the devs/maintainers; I'm not complaining at all, just asking for clarification.

Last edited by slide_rule (2008-06-11 14:34:11)

Allan · 2008-06-11 13:59:53

In your case, I think I would name the package bochs-debug (or something like that) and upload it to the AUR. There is enough changes to make it worthwhile including in the AUR. So long as it has a different name, I see no problems with it.

slide_rule · 2008-06-11 14:33:46

That's what I thought, so I named it bochs-64debug, actually (or maybe -debug64, not at my terminal just now), but that was the package that got the takedown request.

shining · 2008-06-11 14:43:59

slide_rule wrote:

I posted yesterday about the bochs package I uploaded, and got asked by Dragonlord to take it down since it already exists in the [extra] repo. I pulled the package, but I wanted an opinion from the AUR community about how to proceed.
The official [extra] bochs package is compiled without x86-64 emulation support, and without the internal debugger enabled. This is fine if you're emulating an existing OS, but doing os development really needs that debugger. Moreover, compiling bochs with the debugger enabled and >= gcc.4.3 results in a failed build because of C++ namespace issues. I found a patch that fixes this behavior and included it in the package tarball. This required some debugging and searching, so I wanted to share the work I had done so others didn't have to duplicate it.
Since bochs sets many options at compile time, package maintainers have to figure out what the best defaults are, and IMHO the Arch maintainers have done just that, so I didn't want to file a bug report or force everyone who installs bochs to deal with the 64bit emulation and the internal debugger, so I thought I'd create a package offshoot.
Like I said, I do want to follow the AUR guidelines, so I took down the package, but I thought it was worth discussing. Hopefully I'm not coming across as whining about the devs/maintainers; I'm not complaining at all, just asking for clarification.

Isn't the rule below inaccurate, exactly because of this kind of situation ? :

Check [core], [extra], [unstable], and [community] for the package. If it is inside any of those repositories in ANY form, DO NOT submit the package (if the current package is broken or is lacking an included feature then please file a bug report in FlySpray).

It should be clearly explained that in the case the package has worthwhile changes which don't belong to the official packages (because of a more specific user targets or whatever), then it can (should) be uploaded to AUR, with a suffix.

slide_rule · 2008-06-11 15:00:37

Bochs *is* sort of a special case; the internal debugger is an option; it's not a feature that would be "missing," just disabled. I do think it would be better if you could enable/disable the debugger from the .bochsrc config file, but that's an upstream question, and not likely to be changed anytime soon.

Something that might make sense is to distribute the package with the patch, even if the internal debugger isn't enabled, so that recompiles via abs would work out of the box. I think I'll post that to flyspray.

Last edited by slide_rule (2008-06-11 15:08:00)

Allan · 2008-06-11 15:06:25

That rule is mainly to stop people uploading updated packages to the AUR or really simple configuration changes where people should really just use ABS.

Now is this case actually wrong? By the sounds of things, a patch is needed to build the debug support but not the main package so it isn't just a simple configure change. But I suppose the real question is: Is there a disadvantage to having these options in the official build? If it would actually effect the users of the current package, then a bug report asking for these options to be added would not be appropriate. In that case only, you can consider putting the PKGBUILD in the AUR. Just make a good justification for keeping it in the first comment on the AUR page.

Edit: Your solution might be best there...

Last edited by Allan (2008-06-11 15:13:03)

slide_rule · 2008-06-11 15:12:03

Allan wrote:

But I suppose the real question is: Is there a disadvantage to having these options in the official build? If it would actually effect the users of the current package, then a bug report asking for these options to be added would not be appropriate.

According to the bochs documentation, x86-64 support is only about "90% complete and is still experimental," and requires certain other config flags that are also somewhat buggy. The internal debugger slows down emulation, and requires additional user intervention, so it would certainly affect current users.

Ok, I think I'll try re-posting again tonight with more info in the initial comment. Thanks for the help.

drag0nl0rd · 2008-06-11 15:52:12

slide_rule wrote:

Ok, I think I'll try re-posting again tonight with more info in the initial comment. Thanks for the help.

Ok, that's why the package is gone from AUR. After putting comment to the package in AUR I went to IRC to discuss this with other TUs (I don't use bochs, but I was attracted with the same name of the package, which we already provide in [extra] repo).
It really looks like the package can stay in AUR, but at least under a different name then just "bochs" as the package in [extra], I know it was commented inside the PKGBUILD, but it's not enough IMHO.

slide_rule · 2008-06-11 16:37:44

Cool, thanks. Question: do you mean I should change the name of the executable (I assume I'd need to patch Makefiles to do that), or just the package itself?

drag0nl0rd · 2008-06-11 18:02:41

slide_rule wrote:

Cool, thanks. Question: do you mean I should change the name of the executable (I assume I'd need to patch Makefiles to do that), or just the package itself?

IMHO changing package name and adding conflicts= variable into the PKGBUILD should be enough.

slide_rule · 2008-06-11 18:09:26

Sweet, will do. Thanks, all!

superkevjr · 2008-06-13 02:01:35

slide_rule wrote:

That's what I thought, so I named it bochs-64debug, actually (or maybe -debug64, not at my terminal just now), but that was the package that got the takedown request.

It's the reason that I keep most of my pkgbuilds just in my box.

$ find ~/abs -type f -name PKGBUILD | wc -l
293

In personal opinion, same name with apps exiting in aur without any problem, as which need to be compiled before unlike the binary one. And You are the one to decide everything in your box and leave difference between official and unofficial go away, just similar to the point in newsletter-2008-Jun-02:"Arch Is Not a Democracy".

slide_rule · 2008-06-13 02:04:25

Agreed, I've got a collection of recompiled stuff on my box as well: my intention (and I think the intention behind AUR, if I understand correctly) is to save others the work I had to do to get the package working. Arch may not be a democracy, but it is a community.

shining · 2008-06-13 05:56:14

slide_rule wrote:

Agreed, I've got a collection of recompiled stuff on my box as well: my intention (and I think the intention behind AUR, if I understand correctly) is to save others the work I had to do to get the package working. Arch may not be a democracy, but it is a community.

In my opinion, rhere is a subtle difference which makes all the difference here.
If you had work to do to get the package working at all, you should submit a bug report so that it gets fixed.
If you had work to do to get the package working *for you*, for example you had to enable specific features that only you and a few others use, but which would affect most users in a bad way (for example, lower stability, or bloat caused by huge dependencies), then it might be worth submitting on AUR, depending on how straightforward your changes were.

Arch Linux

#1 2008-06-11 13:45:59

advice on user guidelines

#2 2008-06-11 13:59:53

Re: advice on user guidelines

#3 2008-06-11 14:33:46

Re: advice on user guidelines

#4 2008-06-11 14:43:59

Re: advice on user guidelines

#5 2008-06-11 15:00:37

Re: advice on user guidelines

#6 2008-06-11 15:06:25

Re: advice on user guidelines

#7 2008-06-11 15:12:03

Re: advice on user guidelines

#8 2008-06-11 15:52:12

Re: advice on user guidelines

#9 2008-06-11 16:37:44

Re: advice on user guidelines

#10 2008-06-11 18:02:41

Re: advice on user guidelines

#11 2008-06-11 18:09:26

Re: advice on user guidelines

#12 2008-06-13 02:01:35

Re: advice on user guidelines

#13 2008-06-13 02:04:25

Re: advice on user guidelines

#14 2008-06-13 05:56:14

Re: advice on user guidelines

Board footer