Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Xyne
>Well, it also means, for example, that you don't have to keep listing
>things like bash and glibc in literally hundreds of PKGBUILDs.

I understand that argument, but it is framed as if people are writing hundreds
of PKGBUILDs at once and the added deps are overly tedious to include, when in
fact they are written one at a time and it's only a few extra words (at most)
alongside however many constitute the PKGBUILD. For makedeps, most of these are
not even needed because they are indirect deps of base-devel. All runtime deps
should be resolved though, either directly or indirectly.

The only valid technical argument would be if the overhead of the dependency
checks is prohibitive. I expect that it is negligible (but admittedly haven't
checked) and it is worth technical correctness.

It's like quoting path variables in PKGBUILDs: most people build in "sane"
paths but it's still poor form to omit the quotes and assume that no one builds
on paths with spaces. The arguments "but I don't want to type more quotes" and
"but all those quotes across all the PKGBUILDs take so many bytes" are rightly
rejected.



>> There is no "base installation" of Arch Linux. That's one of the defining
>> features of this distro. Forcing some people to install bloat and cruft (or
>> play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
>> wrong.  
>
>There absolutely is a base installation. Unless you are suggesting e.g.
>systemd-less systems constitute a supported Arch Linux installation?

This isn't about what is officially "supported". This is about how one tool
performs a task. Arch provides flexibility. There are custom kernels and
alternative init systems in the AUR for example. If you customize your system
then you are expected to deal with problems arising from that customization
yourself, but core functionality of the package manager should not rely on all
users installing essentially the same base system. We are talking about
dependency resolution here. Pacman is not tied to systemd or whatever else you
consider to be part of a "base installation". It shouldn't even matter what
other packages the user is using as long as pacman's own deps are satisfied.
For dependency resolution, Pacman's job is to determine what the user wants to
install and then figure out what else the user needs to install it. All it
needs to do that is the correct metadata, which is just a few extra words in
some text files. That is better than implicit assumptions that may silently
change in the future.




>I thought that was the point of suggesting that minimalist build chroots
>potentially require base as well...

A chroot that requires all of the base group is not minimal, it's bloated.


It's like a lazy fruit vendor dumping apples, oranges, bananas, etc. into one
giant bin because he can't be bothered to put them in separate bins (even
though he has them, and it would be simple to do), then forcing customers who
only want apples to buy big boxes of mixed fruit so that they can sort out the
apples themselves and throw the rest of the fruit away (after paying for it).


Regards,
Xyne


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Eli Schwartz via aur-general
On 03/22/2017 11:24 PM, Xyne wrote:
> The PKGBUILD should specify all necessary information for full dependency
> resolution without assuming anything other than base-devel*. Extending the
> assumption to the full base group just so some packagers can avoid typing a
> few extra words *once* when they create the PKGBUILD is just laziness. It's 
> not
> even a real burden given that most deps are pulled in indirectly by other
> deps so at most you usually only need to list a few. If a PKGBUILD does not
> contain all information for full dependency resolution (minus base-devel), 
> then
> it is technically incorrect (it lacks required metadata).

Well, it also means, for example, that you don't have to keep listing
things like bash and glibc in literally hundreds of PKGBUILDs.

> There is no "base installation" of Arch Linux. That's one of the defining
> features of this distro. Forcing some people to install bloat and cruft (or
> play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
> wrong.

There absolutely is a base installation. Unless you are suggesting e.g.
systemd-less systems constitute a supported Arch Linux installation?

> It also fails to consider use cases such as minimalist chroots for
> building packages.

I thought that was the point of suggesting that minimalist build chroots
potentially require base as well...

But hey, I am also perfectly happy listing them only as makedepends. :)

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Eli Schwartz via aur-general
On 03/22/2017 10:02 PM, Daniel Micay via aur-general wrote:
> Doesn't the standard chroot end up with all of base and base-devel or
> is that not currently the case?

The "standard chroot" is a help message in makechrootpkg saying
```
The chroot "root" directory must be created via the following
command:
mkarchroot /root base-devel
```
and corresponding automation in archbuild.

mkarchroot is really just a btrfs/CHROOT_VERSION wrapper around pacstrap...

As I said earlier, perhaps this is something that could/should be rethought?

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Xyne
On 2017-03-22 19:17 -0400
Eli Schwartz via aur-general wrote:

>Given that the official instructions for installing Arch boils down to
>"install the base group into a blank partition and arrange a bootloader
>to boot that base group", I feel it is eminently reasonable to assume
>all valid Arch Linux systems have the base group installed... especially
>because some repo packages *are* built with implicit dependencies
>because of that exact logic. You really can't just go around
>uninstalling parts of base, or rather you can, but then it is up to you
>to know when your unsupported actions are likely to break something.
>(I say this with the full knowledge that I myself uninstall certain
>things I don't feel belong in base at all. I am willing to debug my own
>self-inflicted problems...)
>
>Though thinking about this, I actually wonder, maybe devtools should
>instruct you (rhet.) to install both base and base-devel into a build
>chroot...



On 2017-03-22 21:07 -0400
beest wrote:

>I'm also on the side of explicitly assuming that base is installed (and
>having the wiki and PKGBUILD dox reflect as much), but before that there
>should possibly be a discussion about what actually belongs in base in
>the first place. A few folks are of the mind that a good chunk of the
>group is wholly unnecessary and should be culled.


The PKGBUILD should specify all necessary information for full dependency
resolution without assuming anything other than base-devel*. Extending the
assumption to the full base group just so some packagers can avoid typing a
few extra words *once* when they create the PKGBUILD is just laziness. It's not
even a real burden given that most deps are pulled in indirectly by other
deps so at most you usually only need to list a few. If a PKGBUILD does not
contain all information for full dependency resolution (minus base-devel), then
it is technically incorrect (it lacks required metadata).

There is no "base installation" of Arch Linux. That's one of the defining
features of this distro. Forcing some people to install bloat and cruft (or
play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
wrong. It also fails to consider use cases such as minimalist chroots for
building packages.


Regards,
Xyne

* I could even argue that makepkg should check for base-devel and include it in
  dependency resolution automatically with the --syncdeps option.


Re: [aur-general] Review and a bit of other help request

2017-03-22 Thread Eli Schwartz via aur-general
On 03/22/2017 09:53 PM, Konstantin Gizdov wrote:
> Hi again,
> 
> So I updated xrootd and pythia and submitted the relevant deletion
> requests. Now, can I get some package reviews? Thanks.

I know nothing about the specific packages in question, so I will merely
make some general PKGBUILD comments.

${srcdir} and ${pkgdir} must *always* be shell-quoted, as they are
user-controlled filepaths and can contain whitespace.

update-desktop-database, update-mime-database, gtk-update-icon-cache are
pacman hooks, remove them from the root5 install file. You can probably
also drop the pre-remove stuff by now, thereby getting rid of the
install file altogether. (yay!)

Some of your other install files imply that optional dependencies
require being installed at build-time, in which case you should simply
add them as makedepends. If that support means you cannot then uninstall
them (e.g. linking to shared libraries) then they should not be optional
at all. Automagic dependencies are *evil* and should be explicitly
enabled or explicitly disabled.

You use `[[ -d $dir ]] || mkdir $dir` several times, you can just use
`mkdir -p $dir` which does not error when $dir already exists (and
creates parent directories as needed also...).

Make already knows how to read $MAKEFLAGS, no need to specify it on the
command line.

xrootd uses `cmake ... || return 1`, and `make || return 2`, why???
makepkg already knows how to abort as soon as *any* error occurs.

Do not list make as a makedepends, it is assumed users will have
base-devel already installed for building packages.

In root5, I would probably turn $sys_libs into a bash array on general
principle, since bash knows how to expand them into arguments without
depending on ugly things like word-splitting of a variable.
```
declare -a sys_libs
for sys_lib in ...; do
   sys_libs+=("--disable-builtin-${sys_lib}")
done

./configure ... "${sys_libs[@]}"
```

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Doug Newgard
On Wed, 22 Mar 2017 22:02:31 -0400
Daniel Micay via aur-general  wrote:

> On Thu, 2017-03-23 at 01:38 +, Giancarlo Razzolini wrote:
> > Em março 22, 2017 18:12 Doug Newgard escreveu:  
> > > 
> > > There's no specific rule about it. Some packagers will include
> > > packages in base
> > > in the depends, some won't. It's completely up to them.
> > >   
> > 
> > But, if at least the maintainers built their packages using a clean
> > chroot, they
> > would know what they are missing from base to include on depends. I
> > don't think
> > we need to enforce that rule to the AUR, but it is a rule for repo
> > packages for
> > a good reason. We could, however, suggest on the wiki, if it isn't
> > already, that
> > even for the AUR, the *maintainers* build their packages using
> > devtools.
> > 
> > Cheers,
> > Giancarlo Razzolini  
> 
> Doesn't the standard chroot end up with all of base and base-devel or
> is that not currently the case?

All of base-devel, but not all of base.


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Eli Schwartz via aur-general
On 03/22/2017 09:07 PM, beest wrote:
> I'm also on the side of explicitly assuming that base is installed (and
> having the wiki and PKGBUILD dox reflect as much), but before that there
> should possibly be a discussion about what actually belongs in base in
> the first place. A few folks are of the mind that a good chunk of the
> group is wholly unnecessary and should be culled.

I will absolutely agree that there are additional packages in base that
shouldn't be. I have brought this point up before a couple times
Unfortunately, the maintainers of those packages seem to be entirely
happy to leave them as-is, maybe on the assumption borne out in this
thread that no one cares what is in base (except for silly things like
the Installation Guide which no one cares about either, of course).

Bizarrely, other package groups seem to have clearly-defined meanings
which is strongly against the precedent set by the current base group...

fsck/mkfs support for nonstandard filesystems
- xfsprogs
- reiserfsprogs
- jfsutils

Heavily discouraged by pretty much everyone, why on earth would it match
any conceivable definition of "base"...
- netctl :(

Needed for device encryption/LVM/RAID, which not everyone uses
- cryptsetup
- lvm2
- device-mapper
- mdadm

No firm reason for including
- s-nail (an inert mass unless you go out of your way to configure it)
- nano (vi is the standard, and *I* don't even want to include that
  because vim)


I would love for all these to be dropped from base, as I consider them
neither recommended (Scimmia's concept of base IIRC) nor critical (the
intuitive concept of base).

Well, maybe the LVM/encryption stuff could be said to be recommended.
But not critical.

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Daniel Micay via aur-general
On Thu, 2017-03-23 at 01:38 +, Giancarlo Razzolini wrote:
> Em março 22, 2017 18:12 Doug Newgard escreveu:
> > 
> > There's no specific rule about it. Some packagers will include
> > packages in base
> > in the depends, some won't. It's completely up to them.
> > 
> 
> But, if at least the maintainers built their packages using a clean
> chroot, they
> would know what they are missing from base to include on depends. I
> don't think
> we need to enforce that rule to the AUR, but it is a rule for repo
> packages for
> a good reason. We could, however, suggest on the wiki, if it isn't
> already, that
> even for the AUR, the *maintainers* build their packages using
> devtools.
> 
> Cheers,
> Giancarlo Razzolini

Doesn't the standard chroot end up with all of base and base-devel or
is that not currently the case?

signature.asc
Description: This is a digitally signed message part


Re: [aur-general] Review and a bit of other help request

2017-03-22 Thread Konstantin Gizdov
Hi again,

So I updated xrootd and pythia and submitted the relevant deletion
requests. Now, can I get some package reviews? Thanks.

Regards,
Konstantin

On Fri, Mar 17, 2017 at 9:33 PM, Eli Schwartz via aur-general <
aur-general@archlinux.org> wrote:

> On 03/17/2017 02:17 PM, Konstantin Gizdov wrote:
> > Hi Eli and Sebastian,
> >
> > OK, I see the orphan request got approved. Certainly, wasn't looking to
> > draw outrage, but get advice on what the appropriate action. I will
> update
> > the relevant pythia, xrootd and submit deletion request myself for the
> > others.
>
> Thanks for fixing this yourself. It was less about outrage and more
> about being extra-emphatic about what is and isn't appropriate. :)
>
> I save the outrage/abuse for people who have already been told what the
> right thing is, and refuse to listen. Everyone makes mistakes, and that
> is generally okay as long as it was done in good faith and, upon
> realizing the mistake, fixing it.
>
> > As to the package signing, I already know how to detach sign. I also know
> > about the source signing. What is not clear to me is repo-add --sign. The
> > docs say it will update 'the package database'. Which package database?
> > Does AUR keep such info? I though that was for Trusted Users and official
> > repos.
> >
> > What I want to do is essentially to provide a convenient way for people
> to
> > build or directly download pre-built packages, if they choose to, and be
> > able to verify them, without too much hassle. What do you recommend?
> Should
> > I just make a *-bin version on AUR with my signature and detach sign the
> > binaries on my own repo? I thought this was also not the AUR way?
> >
> > Could I get someone's workflow for signed packages as an example?
>
> No, this is entirely separate from the AUR. See the Wiki page for
> "Unofficial user repositories".
>
> Various members of the community host their own prebuilt packages on
> their personal servers or whatever, for example, AUR packages that they
> use and want to sync on multiple computers, or something that takes a
> long compile time and they want to offer in addition to the AUR package.
>
> `repo-add --sign` will allow you to generate a pacman-compatible sync
> repository that can be copied/rsynced to your personal server and then
> added to pacman.conf to download from your server, while signing the
> database itself (it is ideal to sign both the packages, via `makepkg
> --sign`, and the sync database itself).
>
> --
> Eli Schwartz
>
>


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Giancarlo Razzolini

Em março 22, 2017 18:12 Doug Newgard escreveu:


There's no specific rule about it. Some packagers will include packages in base
in the depends, some won't. It's completely up to them.



But, if at least the maintainers built their packages using a clean chroot, they
would know what they are missing from base to include on depends. I don't think
we need to enforce that rule to the AUR, but it is a rule for repo packages for
a good reason. We could, however, suggest on the wiki, if it isn't already, that
even for the AUR, the *maintainers* build their packages using devtools.

Cheers,
Giancarlo Razzolini


pgpQu8AMP50sI.pgp
Description: PGP signature


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread beest
On Wed, Mar 22, 2017 at 07:17:17PM -0400, Eli Schwartz via aur-general wrote:
> Arch Linux does not support people who don't have systemd installed
> though, and regarding Baptiste's initial example of glibc, if you don't
> have glibc installed then your system is so screwed up it's not even
> funny...
> 
> Given that the official instructions for installing Arch boils down to
> "install the base group into a blank partition and arrange a bootloader
> to boot that base group", I feel it is eminently reasonable to assume
> all valid Arch Linux systems have the base group installed... especially
> because some repo packages *are* built with implicit dependencies
> because of that exact logic. You really can't just go around
> uninstalling parts of base, or rather you can, but then it is up to you
> to know when your unsupported actions are likely to break something.
> (I say this with the full knowledge that I myself uninstall certain
> things I don't feel belong in base at all. I am willing to debug my own
> self-inflicted problems...)
> 
> Though thinking about this, I actually wonder, maybe devtools should
> instruct you (rhet.) to install both base and base-devel into a build
> chroot...

Also xorg-server is generally implicit for anything requiring X
(optionally or otherwise), but that's also not really codified anywhere.
The only guidance anyone is given is that only base-devel is assumed to
be installed for makedepends, but in practice that's hardly the sole
circumstance.

I'm also on the side of explicitly assuming that base is installed (and
having the wiki and PKGBUILD dox reflect as much), but before that there
should possibly be a discussion about what actually belongs in base in
the first place. A few folks are of the mind that a good chunk of the
group is wholly unnecessary and should be culled.


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Eli Schwartz via aur-general
On 03/22/2017 05:36 PM, NicoHood wrote:
> On 03/22/2017 10:12 PM, Doug Newgard wrote:
>> On Wed, 22 Mar 2017 21:45:13 +0100
>> Baptiste Jonglez  wrote:
>>>
>>> Am I missing something obvious?
>>>
>>> Thanks,
>>> Baptiste
>>
>> There's no specific rule about it. Some packagers will include packages in 
>> base
>> in the depends, some won't. It's completely up to them.
> 
> You need to include base packages which are not in base-devel, as the
> package won't build without those sometimes. For example some packages
> detect systemd at build time and then adds its service files to the
> package. At least as makedepends they need to be specified.
> 
> I was also angry about this first, but this is actually a more clear way
> to build packages without unnecessary dependencies. Every user should
> build packages using devtools anyways to detect deps properly and to
> produce clean packages.

makedepends, maybe.

Arch Linux does not support people who don't have systemd installed
though, and regarding Baptiste's initial example of glibc, if you don't
have glibc installed then your system is so screwed up it's not even
funny...

Given that the official instructions for installing Arch boils down to
"install the base group into a blank partition and arrange a bootloader
to boot that base group", I feel it is eminently reasonable to assume
all valid Arch Linux systems have the base group installed... especially
because some repo packages *are* built with implicit dependencies
because of that exact logic. You really can't just go around
uninstalling parts of base, or rather you can, but then it is up to you
to know when your unsupported actions are likely to break something.
(I say this with the full knowledge that I myself uninstall certain
things I don't feel belong in base at all. I am willing to debug my own
self-inflicted problems...)

Though thinking about this, I actually wonder, maybe devtools should
instruct you (rhet.) to install both base and base-devel into a build
chroot...

...

@Baptiste,

The fact that namcap emits a warning, doesn't actually mean anything. :)
namcap says/doesn't say a lot of things that are wrong, and all that
*this* means is that namcap doesn't explicitly include code to filter
out warnings for base packages. That could be because a) the namcap
maintainer felt they should be dependencies anyway, or b) no one thought
of it/decided to implement a filter, or c) both.
namcap being what it is, I am 99.% sure it is either b or c.

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread NicoHood
On 03/22/2017 10:12 PM, Doug Newgard wrote:
> On Wed, 22 Mar 2017 21:45:13 +0100
> Baptiste Jonglez  wrote:
>>
>> Am I missing something obvious?
>>
>> Thanks,
>> Baptiste
> 
> There's no specific rule about it. Some packagers will include packages in 
> base
> in the depends, some won't. It's completely up to them.
> 

You need to include base packages which are not in base-devel, as the
package won't build without those sometimes. For example some packages
detect systemd at build time and then adds its service files to the
package. At least as makedepends they need to be specified.

I was also angry about this first, but this is actually a more clear way
to build packages without unnecessary dependencies. Every user should
build packages using devtools anyways to detect deps properly and to
produce clean packages.

~Nico



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Lex Black
Am 22. März 2017 21:56:57 MEZ schrieb "Bartłomiej Piotrowski" 
:
>On 2017-03-22 21:51, Lex Black wrote:
>> Base and base-devel are a requirement for using the AUR and those
>packages shouldn't be added to the depends.
>> 
>> See the prerequisites on the AUR wiki page.
>> 
>
>Well, no.
>
>Someone who builds a package is expected to have base-devel installed.
>It does not apply to the base group. And worth noting, base-devel does
>not include base.
>
>Bartłomiej

Ah, kinda on the wrong way. Dunno why I was thinking base-devel would include 
base.
Thanks for the correction


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Doug Newgard
On Wed, 22 Mar 2017 21:45:13 +0100
Baptiste Jonglez  wrote:
> 
> Am I missing something obvious?
> 
> Thanks,
> Baptiste

There's no specific rule about it. Some packagers will include packages in base
in the depends, some won't. It's completely up to them.


pgp2Ne9u1FMD9.pgp
Description: OpenPGP digital signature


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Tinu Weber
On Wed, Mar 22, 2017 at 21:51:50 +0100, Lex Black wrote:
> Base and base-devel are a requirement for using the AUR and those
> packages shouldn't be added to the depends.
> 
> See the prerequisites on the AUR wiki page.

The policy is only about base-devel; for base, there does not appear to
be a clear policy.

I personally always put those packages in the dependency list, because I
consider the choice of packages in base to be extremely arbitrary. But
some TUs and devs apparently do not do that, which is probably why there
is this "troubleshooting" part in [2], where they recommend installing
*all* of base.

[1] 
https://wiki.archlinux.org/index.php/Arch_User_Repository#Foo_in_the_AUR_does_not_compile_when_I_run_makepkg.3B_what_should_I_do.3F


signature.asc
Description: PGP signature


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Bartłomiej Piotrowski
On 2017-03-22 21:51, Lex Black wrote:
> Base and base-devel are a requirement for using the AUR and those packages 
> shouldn't be added to the depends.
> 
> See the prerequisites on the AUR wiki page.
> 

Well, no.

Someone who builds a package is expected to have base-devel installed.
It does not apply to the base group. And worth noting, base-devel does
not include base.

Bartłomiej


Re: [aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Lex Black
Base and base-devel are a requirement for using the AUR and those packages 
shouldn't be added to the depends.

See the prerequisites on the AUR wiki page.


[aur-general] Should "base" packages be listed as dependencies?

2017-03-22 Thread Baptiste Jonglez
Hi,

I was pretty confident that "base" packages should be listed as
dependencies in PKGBUILDs, i.e. they are not assumed to be installed (as
opposed to "base-devel" for build dependencies).

This belief is reinforced by the fact that namcap gives dependencies error
about packages such as glibc (which is in "base"):

E: Dependency glibc detected and not included (libraries 
['usr/lib/libc.so.6', 'usr/lib/libcrypt.so.1'] needed in files 
['usr/lib/libcli.so.1.9.7'])

But I could not find any documentation about this.  On the contrary, this
wiki page [1] says the opposite:

In addition, the base group is assumed to be installed on *all* Arch
systems.

Am I missing something obvious?

Thanks,
Baptiste

[1] https://wiki.archlinux.org/index.php/Makepkg#Usage


signature.asc
Description: PGP signature