You are not logged in.

#1 2020-11-03 13:00:58

Nocifer
Member
Registered: 2019-05-23
Posts: 13

Best practices to partially build a split PKGBUILD?

Hello,

Let's say I have a PKGBUILD with pkgbase='package' and pkgname=('package-one' 'package-two' 'package-three'), with the 3 latter packages sharing sources and part of the build process with the base package. Searching on the AUR will provide the user with these 3 seemingly separate packages to choose from, and inside the PKGBUILD I can provide them with some variable that they can use to dynamically build only the single package that they need.

The problem is that this variable needs to have been set to a default value beforehand, and that value can not change dynamically based on which package the user has chosen to install, but only by manually editing the PKGBUILD. So if I have the variable set by default to 'package-one', then even if the user has searched for and chosen to install e.g. 'package-three', they'll still get a PKGBUILD with 'package-one' set and thus they will either have to manually edit it in order to set 'package-three', or they will instead get to build and install the wrong package, which kind of breaks the illusion of having separate packages in a single PKGBUILD.

So here's my TL;DR question: if I do not want all the packages contained in a split PKGBUILD installed by default, but only the specific package the user has searched for and chosen to install, then should I be using a split PKGBUILD, making the user have to manually edit it and choose the correct package, or am I better off splitting the packages into their own PKGBUILDs, even though the user will then have to potentially download the same (sizable) sources more than once?

Thanks.

Offline

#2 2020-11-03 13:18:37

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Best practices to partially build a split PKGBUILD?

Nocifer wrote:

I can provide them with some variable that they can use to dynamically build only the single package that they need.

I'd not bother with that - but as long as it's otherwise harmless, you can make it optional: e.g., if it is defined only one package will build, otherwise all three will, and by default have it not defined (and in that case you can use an environment variable that would not be set in the PKGBUILD at all but may be set by the user before running makepkg).

Nocifer wrote:

So if I have the variable set by default to 'package-one'

Don't do that.  If you do your PKGBUILD is simply broken and either needs to be fixed or removed from the AUR.

Nocifer wrote:

... sharing sources and part of the build process ...

Part?  There is only one build function in a PKGBUILD whether it's for a split package or not.

Please provide the actual PKGBUILD so we can see what you are talking about.  But in any case, the answer will be simply don't do any such thing.  I initially thought (from the title) that this question was from the perspective of a user: having a simple way to build / package just a single package from a properly written split package PKGBUILD would be a discussion worth having; but as a packager it is your job just to package it properly.

Last edited by Trilby (2020-11-03 14:38:54)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2020-11-03 14:36:59

a821
Member
Registered: 2012-10-31
Posts: 381

Re: Best practices to partially build a split PKGBUILD?

nocifer wrote:

...even though the user will then have to potentially download the same (sizable) sources more than once?

See SRCDEST in makepkg.conf(5).

AFAIK, split PKGBUILDs are not meant to be built separately. It's all or nothing. You are suppose to install the package(s) you want after building with `pacman -U`. There used to be an option to build single packages but it was removed at some point, IIRC.

Edit: the option was removed here

Last edited by a821 (2020-11-03 14:46:42)

Offline

#4 2020-11-03 21:46:13

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Best practices to partially build a split PKGBUILD?

To clarify, the removed option only permitted you to run a single package_*() function, all components of the split package were always built in build() but only one "make install" got run.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#5 2020-11-03 23:11:19

Nocifer
Member
Registered: 2019-05-23
Posts: 13

Re: Best practices to partially build a split PKGBUILD?

Alright, here's my deal, I'll try to be brief about it.

My actual case is trying to build a PKGBUILD for the Japanese IME called Mozc, which has 3 distinct flavors that should be supported independently: one is building it for IBus, one for Fcitx (another IM framework) and one for Emacs (apparently it has its own IM engine built in; there's a chance I'm misreading this part, but that's of no practical concern here). The Mozc source files are fit for all use cases, and it's up to the user to choose what to do with them.

Currently, the situation with Mozc is a right mess in many aspects (e.g. there isn't even a Mozc package for IBus in the binary repos, only user-created ones in the AUR) but to keep it short, the issue I'm trying to tackle begins with the fact that most all Mozc packages in the AUR are built as a variation of this one here: https://aur.archlinux.org/cgit/aur.git/ … ILD?h=mozc

As you can see, it uses a base package 'mozc' and utilizes custom variables to let the user select if they want to build the packages for IBus and/or for emacs, or possibly for neither (that would probably be useless but it's very possible), and then it dynamically adds the extra parameters to the build process and enables the optional packages 'ibus-mozc' and 'emacs-mozc'.

This approach rubs me wrong because a) it's a bit too convoluted, b) it makes it so that if a user tries to install the AUR package 'emacs-mozc' but doesn't edit the PKGBUILD that gets downloaded, which is still the base 'mozc' one, they will instead by default install 'ibus-mozc' (this is the "variable set to package-one by default" issue I mentioned previously), and c) it doesn't account for the Fcitx version of Mozc.

I initially tried to also follow this approach and just clean things up a bit and update the various components to their most current versions etc, and also add Fcitx support; something like this (don't mind the specifics, this package is for a slightly different version of Mozc than the first PKGBUILD): https://pastebin.com/KiL88MLL

And to be honest it works nicely for what it is, despite using variables to control which package gets built (which you said is a no-no). But as I was finishing it up, it occurred to me that it doesn't really solve issues 1) and 2) above. In other words, it's still convoluted and it still doesn't allow the user to directly install a specific subpackage by name, unless they manually edit the PKGBUILD and change the variables. So even though all these packages share the same sources and almost the whole build process (which by the way is something I read earlier today in this comment of yours when I was searching the forum for inspiration: https://bbs.archlinux.org/viewtopic.php … 0#p1933020 ), I ended up not liking this solution at all.

So going by the gtk/qt & python2/python3 logic you very helpfully mentioned in that comment, I'm currently considering doing what I originally intended and splitting the package by either creating 4 normal packages, one for each of the 3 flavors and one for the 'mozc' base, or creating 3 split packages, one for each flavor, which will include the 'mozc' base and will install everything without using any special variables.

The former approach produces the problem that for the first flavor to be installed, the exact same sources will have to be downloaded twice (once for the base package and then once more for the flavor) but is otherwise the cleanest solution; while the latter one seems to me like the overall better one, with the harmless caveat that each new flavor that gets installed will build and reinstall a new 'mozc' base package that will overwrite the already installed one (also there was one other, more serious caveat I think had occurred to me earlier when thinking about this, but for the life of me I can't put my finger on it right now).

And there's also one more approach: bundle base + flavor together, in a single package that contains all their files. This is the approach that the 'fcitc-mozx' package in the official repos  takes, but IMO it's not so good because it will produce unneeded conflicts if a user tries to install any other mozc-based package (e.g. 'emacs-mozc' for use with emacs).

So that's it, in a slightly-more-spacious-than-average nutshell. Between these 4 approaches, which could be considered the best?

P.S. - Please no one mention the fact that there's already a bunch of mozc-* packages in the AUR and yet here I am ready to create a few more. Let's just say that for the time being I'm only asking for the sake of debate tongue

Offline

#6 2020-11-03 23:37:49

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Best practices to partially build a split PKGBUILD?

AUR helpers should generally be considered responsible enough to install only some packages in a split package, FWIW. The user can also manually do this via makepkg --packagelist | sed '/pkgname-to-skip/d' | sudo pacman -U -

(or manually copy-paste some names into pacman -U)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#7 2020-11-04 00:02:53

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Best practices to partially build a split PKGBUILD?

eschwartz wrote:

AUR helpers should generally be considered responsible enough...

That seems a liberal use of "should be" that is very different in meaning from "are".  But in any case, AUR helpers strengths or weaknesses really should not have any part in the determination on how to package.  AUR helpers are written to work with AUR packages, not the other way around.  PKGBUILDs should be written to work with makepkg/pacman; if a helper chokes on it, that's a bug to be sent to the aur helper author.

Nocifer wrote:

either creating 4 normal packages ... or creating 3 split packages

Why is creating four split packages not an option?  One PKGBUILD that creates the mozc core content, and three more for each 'flavor'.  Each of the flavors would then just depend on the core package.

Nocifer wrote:

the harmless caveat that each new flavor that gets installed will build and reinstall a new 'mozc' base package that will overwrite the already installed one...

If I'm reading that right, that'd not be harmless.  Pacman will refuse to install a package that would overwrite files belonging to another package.

So it sounds to me like this should be one PKGBUILD with either 3 or 4 split packages.  Whether 3 or 4 would be best would be informed by whether it is likely or possible for multiple flavors to be installed at once (which seems to be the case).  If so, then you should definitely have 4 packages in the split package: mozc (or mozc-common if that name works better), then each of the flavors (e.g., mozc-emacs ...) each of which will depend on mocz (or mozc-common).


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#8 2020-11-06 11:25:58

Nocifer
Member
Registered: 2019-05-23
Posts: 13

Re: Best practices to partially build a split PKGBUILD?

Sorry for the extremely late reply, I totally forgot about this thread, what with the US elections and all that.

Regarding AUR helpers, thanks @eschwartz for the info, they're certainly something to keep in mind but I too think it's best practice to make my PKGBUILDs in a way that makes it possible to build them properly with only makepkg.

Trilby wrote:
Nocifer wrote:

either creating 4 normal packages ... or creating 3 split packages

Why is creating four split packages not an option?  One PKGBUILD that creates the mozc core content, and three more for each 'flavor'.  Each of the flavors would then just depend on the core package.

Yeah, that's exactly what I meant with "4 normal packages": 4 completely separate packages, each with its own PKGBUILD, with the three flavor packages depending on the base mozc package. As I said, that could prove to be the cleanest solution, but it has the unfortunate caveat that the exact same sources would have to be downloaded twice for each install (i.e., once for mozc and once more for each of ibus-mozc/fcitx-mozc/emacs-mozc). Unless there is a way to make makepkg/pacman share sources between separate packages, this is the main reason why a split 4-in-1 package feels enticing to me.

Trilby wrote:
Nocifer wrote:

the harmless caveat that each new flavor that gets installed will build and reinstall a new 'mozc' base package that will overwrite the already installed one...

If I'm reading that right, that'd not be harmless.  Pacman will refuse to install a package that would overwrite files belonging to another package.

But if we're talking about the exact same package that provides these files (the mozc base), then pacman should just trigger a re-install warning but still allow the user to install it, right? Or could it be that being part of a split package changes this behavior and pacman will behave as if installing different packages? I hadn't thought of this possibility, I think later today I should have a go at testing this scenario.

Trilby wrote:

So it sounds to me like this should be one PKGBUILD with either 3 or 4 split packages.  Whether 3 or 4 would be best would be informed by whether it is likely or possible for multiple flavors to be installed at once (which seems to be the case).  If so, then you should definitely have 4 packages in the split package: mozc (or mozc-common if that name works better), then each of the flavors (e.g., mozc-emacs ...) each of which will depend on mocz (or mozc-common).

So, you're saying I should do what I first tried to do in the PKGBUILD I posted in my previous post? That was a single PKGBUILD containing a base mozc which would always be installed, and then the 3 flavor packages, each one depending on the base mozc, and each one only getting installed when the user has opted to do so via a variable in the PKGBUILD.

But this does not solve the problem with the extra variables controlling what gets installed, which you said is not really a good practice. Do you know of any other way I could do this without resorting to variables?

Also, it does not solve the problem that if I end up using variables, the PKGBUILD will by default always install the base mozc package plus whatever flavor I have initially enabled (e.g. ibus-mozc), so if the user tries to directly install another flavor (e.g. fcitx-mozc) by searching for it on the AUR web interface and downloading the PKGBUILD and immediately running makepkg on it or, even worse, by running something like yay -S fcitx-mozc (yeah, at some point we have to consider that AUR helpers are a thing for most people), they will still only get the default flavor unless they edit the PKGBUILD manually and change those variables to make it install the stuff they want (e.g. fcitx-mozc). So, we're kind of back to square one :/

Offline

#9 2020-11-06 13:14:41

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Best practices to partially build a split PKGBUILD?

Nocifer wrote:
Trilby wrote:

Why is creating four split packages not an option?  One PKGBUILD

Yeah, that's exactly what I meant with "4 normal packages": 4 completely separate packages, each with its own PKGBUILD

Ah, no, this is not the same.  I'm suggesting ONE PKGBUILD that creates 4 packages.

Nocifer wrote:

But if we're talking about the exact same package that provides these files (the mozc base), then pacman should just trigger a re-install warning but still allow the user to install it, right?

I don't follow.  If a user needs to install mozc-emacs which depends on mozc (or mozc-core or whatever it ends up being called) but that dependency is already installed, then there is no concern at all.

Nocifer wrote:

So, you're saying I should do what I first tried to do in the PKGBUILD I posted in my previous post? That was a single PKGBUILD containing a base mozc which would always be installed, and then the 3 flavor packages, each one depending on the base mozc, and each one only getting installed when the user has opted to do so via a variable in the PKGBUILD.

NO.  No variable.  Just a normal split package that creates 4 packages.  Nothing else.

Nocifer wrote:

... the PKGBUILD will by default always install ...

PKGBUILDs don't install anything.  They are used for building packages.

Nocifer wrote:

... if the user tries to directly install another flavor (e.g. fcitx-mozc) by searching for it on the AUR web interface and downloading the PKGBUILD and immediately running makepkg on it ... they will still only get the default flavor

NO, they will get the core package and all three flavors built.  Then they chose which ones to install.

Nocifer wrote:

... or, even worse, by running something like yay -S fcitx-mozc ...

I have no idea how yay handles split packages.  If it handles them appropriately, there'd be no problem.  If it doesn't, that's yay's problem not yours.  Again, do not package incorrectly to try to compensate for poorly made AUR helpers:

Trilby wrote:

AUR helpers are written to work with AUR packages, not the other way around.

If it is trivial to add something that might be useful of AUR helpers, then have at it as long as it 1) doesn't violate packaging standards, 2) doesn't break things, or 3) doesn't do stupid things when users use the officially supported tools.

Really, you're making this far to complicated.  Package properly.  That's it.  If yay chokes on a properly written PKGBUILD, send a PR to yay's development team if you want it fixed.

Last edited by Trilby (2020-11-06 13:15:45)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#10 2020-11-06 13:15:07

Omar007
Member
Registered: 2015-04-09
Posts: 368

Re: Best practices to partially build a split PKGBUILD?

The general idea is that, if the source and build is the same for all but the difference is with the included/packaged files, to do something akin to

pkgbase=mozc
pgkname=(mozc mozc-ibus mozc-emacs ...)
source=(https://...)
...

build() {
    make all    # or w/e the build command is to compile everything and all variants properly.
}

# This should contain all the files that are shared among the variants
package_mozc() {
    make install-common   # if something like that is available to install shared files/libs only
    install -Dm644 ...    # to manually put the relevant common files at the correct location
}

# This should contain ibus related files only!
package_mozc-ibus() {
    depends=(mozc)

    make install-ibus    # if something like that is available to install ibus specific files
    install -Dm644 ...   # to manually put the relevant ibus files at the correct location. ibus only!
}

package_mozc-emacs() {
    depends=(mozc)

    ...
}

...

Now, if the source is the same but the build process differs for each of these (so the actions you need to do in `build()` are not the same for all of them and it's not a matter of just `make all` or something akin to that, then 4 completely separate PKGBUILDs would probably be the way to go even though that would seem to cause a lot of redundant information, downloads, etc across the PKGBUILDs.

If an AUR helper has problems with that, that is something to take up with the helper's devs and that is something for them to fix, not you or anyone here.

Last edited by Omar007 (2020-11-06 13:17:47)

Offline

#11 2020-11-06 13:30:31

a821
Member
Registered: 2012-10-31
Posts: 381

Re: Best practices to partially build a split PKGBUILD?

Nocifer wrote:

Yeah, that's exactly what I meant with "4 normal packages": 4 completely separate packages, each with its own PKGBUILD, with the three flavor packages depending on the base mozc package. As I said, that could prove to be the cleanest solution, but it has the unfortunate caveat that the exact same sources would have to be downloaded twice for each install (i.e., once for mozc and once more for each of ibus-mozc/fcitx-mozc/emacs-mozc). Unless there is a way to make makepkg/pacman share sources between separate packages, this is the main reason why a split 4-in-1 package feels enticing to me.

which is what I said about the SRCDEST variable. And if you don't want to set it, you can copy the sources to the respective PKGBUILD directory.

Trilby wrote:
Nocifer wrote:

the harmless caveat that each new flavor that gets installed will build and reinstall a new 'mozc' base package that will overwrite the already installed one...

If I'm reading that right, that'd not be harmless.  Pacman will refuse to install a package that would overwrite files belonging to another package.

Nocifer wrote:

But if we're talking about the exact same package that provides these files (the mozc base), then pacman should just trigger a re-install warning but still allow the user to install it, right? Or could it be that being part of a split package changes this behavior and pacman will behave as if installing different packages? I hadn't thought of this possibility, I think later today I should have a go at testing this scenario.

What!? No idea what you mean here. You cannot install two packages with conflicting files as Trilby said. If these is the case you need to set the `conflicts` array properly.

Nocifer wrote:
Trilby wrote:

So it sounds to me like this should be one PKGBUILD with either 3 or 4 split packages.  Whether 3 or 4 would be best would be informed by whether it is likely or possible for multiple flavors to be installed at once (which seems to be the case).  If so, then you should definitely have 4 packages in the split package: mozc (or mozc-common if that name works better), then each of the flavors (e.g., mozc-emacs ...) each of which will depend on mocz (or mozc-common).

So, you're saying I should do what I first tried to do in the PKGBUILD I posted in my previous post? That was a single PKGBUILD containing a base mozc which would always be installed, and then the 3 flavor packages, each one depending on the base mozc, and each one only getting installed when the user has opted to do so via a variable in the PKGBUILD.

But this does not solve the problem with the extra variables controlling what gets installed, which you said is not really a good practice. Do you know of any other way I could do this without resorting to variables?

I do not see what the problem is if you build all packages with makepkg and then install the flavor you want. There is no need to mess with environment variables. The only inconvenience is maybe a longer build time (I assume it is not significant). If this is too inconvenient, then go for 3/4 PKGBUILDs.

Nocifer wrote:

Also, it does not solve the problem that if I end up using variables, the PKGBUILD will by default always install the base mozc package plus whatever flavor I have initially enabled (e.g. ibus-mozc), so if the user tries to directly install another flavor (e.g. fcitx-mozc) by searching for it on the AUR web interface and downloading the PKGBUILD and immediately running makepkg on it or, even worse, by running something like yay -S fcitx-mozc (yeah, at some point we have to consider that AUR helpers are a thing for most people), they will still only get the default flavor unless they edit the PKGBUILD manually and change those variables to make it install the stuff they want (e.g. fcitx-mozc). So, we're kind of back to square one hmm

As I said above, no need for variables.

Edit: too slow...

Last edited by a821 (2020-11-06 13:31:02)

Offline

#12 2020-11-08 03:39:00

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Best practices to partially build a split PKGBUILD?

Trilby wrote:
eschwartz wrote:

AUR helpers should generally be considered responsible enough...

That seems a liberal use of "should be" that is very different in meaning from "are".  But in any case, AUR helpers strengths or weaknesses really should not have any part in the determination on how to package.  AUR helpers are written to work with AUR packages, not the other way around.  PKGBUILDs should be written to work with makepkg/pacman; if a helper chokes on it, that's a bug to be sent to the aur helper author.

It seems we agree.. my comment was meant to imply that it's possible to do it correctly, makepkg provides the tools to do it (e.g. --packagelist) and therefore I only care if AUR helpers "should" and "can theoretically" do it.

Hence, in my mind, there is no need for the OP to worry about how AUR helpers will do it.

...

I don't really get the OP's suggested goal, it seems like there was a proposal to  upload multiple PKGBUILDs each providing "mozc" so that any of the 3 would install or reinstall "mozc"? This is not going to fly... only one PKGBUILD in the AUR can lay claim to a given pkgname, working around this by hacking the .SRCINFO would be maliciously lying about the contents of the PKGBUILD and thus be a bannable offense.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#13 2020-11-16 17:12:59

Nocifer
Member
Registered: 2019-05-23
Posts: 13

Re: Best practices to partially build a split PKGBUILD?

Alright, let me try to clear up some misunderstandings, because either I do not at all understand the AUR packaging process (quite possible) or I've simply failed to explain the situation adequately.

TL;DR: I'm not advocating for using custom variables, conditionally building only parts of a PKGBUILD, or building a PKGBUILD with AUR helpers' quirks or limitations in mind. I'm not trying to build a monster of a PKGBUILD that implements all this stuff. On the contrary, I'm vehemently against thist stuff, and I'm simply trying to fix/replace a family of PKGBUILDs which contain all this stuff and which CURRENTLY EXIST on the AUR. And all I'm asking is for some advice on how to better do that, instead of implementing a solution all on my own and possibly making things worse.

***************

1) I'd like to kindly reiterate that the first PKGBUILD I provided back in my second post is a great example of the kind of PKGBUILD I've been trying to describe: a single, split PKGBUILD that by default only builds 'mozc' and 'ibus-mozc', but also includes a custom variable (disabled by default) that when enabled will make the PKGBUILD to build an additional, third package 'emacs-mozc'.

2) This PKGBUILD is not a figment of my imagination; it already exists on the AUR and is but one of many like it, because as I've already said, there are multiple variants of 'mozc-*' on the AUR and most of them seem to follow the same basic recipe of using variables to control what packages get built. In other words: by default, these split PKGBUILDs do NOT build all their packages.

3) Precisely because I find this whole process convoluted and messy, I decided to create a new PKGBUILD. I initially imitated that basic recipe (i.e. using variables) and only tried to optimize/modernize it, but in the process I realized all these issues that have already been mentioned, both by me and by others. That's why I decided that a split PKGBUILD is NOT the proper way to go.

4) After deciding that, I came to the conclusion that there really are only two good solutions:

a) A normal PKGBUILD for 'mozc' and one more normal PKGBUILD for each of 'ibus-mozc', 'fcitx-mozc' and 'emacs-mozc', for a grand total of four (4) separate, normal PKGBUILDs.

b) A split PKGBUILD for each of 'mozc'+'ibus-mozc', 'mozc'+'fcitx-mozc' and 'mozc'+'emacs-mozc', for a grand total of three (3) separate, split PKGBUILDs.

5) After deciding that, I had the following apprehensions about each solution:

For solution (a), I was worried that when a user would try to install the flavor of their choice, the Mozc sources would have to be downloaded twice: once for 'mozc' and once more for the flavor. This would at the very least be wasteful in bandwidth and disk space.

For solution (b), I was worried that if a user ever tried to install a second flavor in parallel with the first one, then the split PKGBUILD would rebuild the base 'mozc' package and then try to overwrite the 'mozc' package previously installed by the first flavor, resulting in the harmless (as I already said) caveat that this would produce a makepkg warning. And I really wanted to find out if maybe there was an even better solution that would do away with that warning.

6) At that point I decided to come here and ask you people for advice. Initially I was only going to ask about my two "good solutions", but after stumbling on Trilby's quote about a split PKGBUILD being a good solution for packages that share the same sources and build process (which the mozc* packages do) I decided to also ask about that, just in case I was wrong and the split PKGBUILD solutions already on the AUR were right all along and I was simply nitpicking. Hence my initial question in my first post: "should I be using a split PKGBUILD, making the user have to manually edit it and choose the correct package, or am I better off splitting the packages into their own PKGBUILDs?"

7) I think it can be safely said that you guys mostly agree with my initial decision that in this particular case, a split PKGBUILD is a no go. Additionally, I have decided that having a harmless reinstall warning is much better than having the same sources downloaded twice. So, I will go with solution (b) and create three (3) split PKGBUILDS, each responsible for installing the base 'mozc' package (which I'll indeed rename to 'mozc-common', since on its own it's pretty much useless) plus one of the three flavors 'ibus-mozc', 'fcitx-mozc' and 'emacs-mozc'. There will be no variables, no .SRCINFO maliciously lying about what gets installed, no nothing of that sort. Just simple PKGBUILDs that imperatively build all of their contents in one go. I do hope this kind of solution will not be considered as a bannable offense, but if anyone finds issue with it, I'll be more than happy to hear it.

Thank you all for your input so far, it's kindly appreciated.

Offline

#14 2020-11-16 17:21:36

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Best practices to partially build a split PKGBUILD?

RE 1, 2, and 3: I don't think anyone here is questioning your motives.  There is a lot of garbage in the AUR and it can be confusing.  But if you are asking about best practices, that's what we'll try to advise on, actual best practices, not what someone else may have gotten away with doing previously.


Nocifer wrote:

4) After deciding that, I came to the conclusion that there really are only two good solutions:

a) A normal PKGBUILD for 'mozc' and one more normal PKGBUILD for each of 'ibus-mozc', 'fcitx-mozc' and 'emacs-mozc', for a grand total of four (4) separate, normal PKGBUILDs.

b) A split PKGBUILD for each of 'mozc'+'ibus-mozc', 'mozc'+'fcitx-mozc' and 'mozc'+'emacs-mozc', for a grand total of three (3) separate, split PKGBUILDs.

Option 'a' is a viable solution, but I'd advise against it.  Option 'b' is not viable.  Do not do that.  It's WRONG.

Nocifer wrote:

I think it can be safely said that you guys mostly agree with my initial decision that in this particular case, a split PKGBUILD is a no go.

No.  I definitely don't agree.  I can't speak for anyone else, but from my reading of this thread I just don't know where you are getting this.  A split PKGBUILD is definitely not a "no go"; it is a very good option - and as I've repeatedly advocated, it's probably the best option.  But this is getting a bit silly.  You seem to only hear what you want to hear, even when it is the complete opposite of what we actually say.

Last edited by Trilby (2020-11-16 19:11:24)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#15 2020-11-16 19:08:02

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Best practices to partially build a split PKGBUILD?

Nocifer wrote:

Additionally, I have decided that having a harmless reinstall warning is much better than having the same sources downloaded twice.

The same sources will not be downloaded twice, if the user defines a shared $SRCDEST and multiple PKGBUILDs download the same named file.

Nocifer wrote:

So, I will go with solution (b) and create three (3) split PKGBUILDS, each responsible for installing the base 'mozc' package (which I'll indeed rename to 'mozc-common', since on its own it's pretty much useless) plus one of the three flavors 'ibus-mozc', 'fcitx-mozc' and 'emacs-mozc'. There will be no variables, no .SRCINFO maliciously lying about what gets installed, no nothing of that sort. Just simple PKGBUILDs that imperatively build all of their contents in one go. I do hope this kind of solution will not be considered as a bannable offense, but if anyone finds issue with it, I'll be more than happy to hear it.

The AUR would reject the package, saying that the package "mozc-common" already exists in the AUR and you cannot re-upload it.

Now, it's possible to have the .SRCINFO lie by manually removing references to mozc-common, so that the AUR would think it isn't a split PKGBUILD and permit you to upload a PKGBUILD that does contain mozc-common.
And downloading it and running makepkg would produce both packages. But you agreed that isn't a good idea. tongue

(Note: I mentioned it being a bannable offense not because I thought you were going to do it, but for the sake of contrast.)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB